At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote: >Ian G wrote, On 2008-09-22 09:45: >> Hi all, > >Hi Ian, >This reply isn't complete. I'm just going to discuss the questions with >easy answers. > >> * the following extended key usage fields within roots: >> + Server Authentication >> + Client AUthentication >> + Secure Email >> + ... >> (list...) >> (format!) >> + all or none or? > >RFC 3280 and RFC 5280 both contain this interest statement in the >section that defines the EKU extension: > >+ In general, this extension will appear only in end entity certificates. > >That statement doesn't use any of the reserved keywords "MUST" "MUST NOT" >or "SHOULD", and appears to be a statement of intention or expectation, >not imposing any requirement. That RFC section goes on to say "If the >extension is present, then the certificate MUST only be used for one of >the purposes indicated.", and indeed, NSS will impose EKU limitations on >any cert that bears them, even root CA certs.
Welcome to the waffling words in PKIX. > >In CA certs, NSS understands the EKUs to mean "this CA can only issue >certs valid for these purposes", rather than meaning that the CA cert >itself can be used for those purposes. I would argue that that interpretation of the MUST above is completely wrong. I see nothing in section 4.2.1.12 that indicates that this extension is meant to limit CAs, and there is plenty of opportunity for it to do so. Following this logic, a CA with no EKUs would not be able to issue certs with any EKU at all. Remember, new EKUs are defined by the IETF all the time. >Generally owners of root certs want them to be as unlimited as possible. >We've even received requests from CAs to have NSS trust their roots for >all purposes, even though the root CA cert has an EKU that limits it. >So, I would expect any new CA certs not to have this extension. You should expect that anyway. Following the spec, the CA cert itself should not be used for authenticating web servers, email clients, and so on. > > * Naming - any constraints? >> + O >> + CN >> + OU - optional? >> + Firefox 3 displays O whereas Thunderbird displays CN. >> What is the preference here? >> Most software seems to prefer CN? > >It depends on the purpose for which the cert is being used. But Ian was asking about *root certs*. The CN in a root cert is really the "common name" of the entity who is the that root authority. Ian: are you saying that Firefox and Thunderbird show different fields for the names of root certs? >An email cert >usually identifies a person, and the CN will be the person's name, so it's >appropriate to display the CN for an email cert. In SSL server certs, >the CN historically held the server DNS name (although that is non-standard >and now deprecated), and the name that identifies the legal entity behind >the server is recorded in another attribute. (BTW, the standard place for >SSL server DNS names is the Subject Alternative Name extension, NOT the CN.) Quite true. > >> * legal notices should be in which field? >> + OU >> + duplicates are ok? >> + "Netscape Certificate Comment" ? >> + Netscape Certificate Authority Policy URL > >I'd say: none of the above. There is an extension for this purpose. >Those things do NOT belong in the cert's Subject name. They do NOT >identify the cert's subject. The Certificate Policies extension >serves this purpose, IINM. Fully agree here. They should only be in certificatePolicies. > >> * support email addresses go in >> + E field? (Is 'E' the name?) > >For email certs, email addresses MUST go in the Subject Alternative Name >extension. That's the standardized place for email addresses in email >certs. If the email address is just a reference for support, and the >cert itself is not acting as an email signing or encryption cert, then >I suppose it could go in the cert Subject Name. Gaaah. Why is there an email address in a root certificate? > > Technical Requirements >> >> * cA=true obligatory and 'critical' > >Yes. > >> * size is RSA 4096 >> + ECC equivalent? >> + any viewpoint on size, etc? > >It doesn't make sense to use a huge RSA key size with a really weak cipher >or hash. NIST published some tables of equivalent strengths of hashes, >ciphers and key sizes. They show equivalent key sizes for DSA, RSA, ECDSA, >symmetric ciphers (3DES, AES) and hashes. See tables 2 and 3, pp 63-64 in >http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf An RSA 4096 is equivalent in strength to about 150 bits, a weird length. Why not do 3072, which is equivalent to AES-128? As for the ECC equivalent of 4096, that would be about 300 bits, a weird length. Why not do 256, maybe even using a NIST-recommended curve like P-256? > > * expiry should be? >> + minimum 8 years? >> + maximum 30 years? > >In that same NIST publication there is a table of recommended key sizes >to use for secrets that need to be protected until year 2010, 2030, and >beyond. It's table 4, page 66. Table 4 is *not* talking about lifetimes of digital signature algorithms: it is talking about symmetric algorithms that do not weaken with research. RSA has already weakened twice, and it is likely to weaken again within its lifetime. Determining the lifetime of a trust anchor key has many aspects. How strong is the key against the best-known attacks? How likely is it that someone will copy the private key and use it without you knowing about it? What is the cost to the organization if there is a compromise and the key needs to be revoked? Only the first has practical answers. > >> * format is PKCS1, Hashes are SHA1 >> + any chance of SHA-256? > >SHA1 is definitely incongruent with a 4k key size. ...but still useful because of its wide deployment. For a trust anchor, you are really only concerned with the preimage strength, not the collision strength, of the hash algorithm. 160 bits is enough for anyone for the foreseeable future. The more interesting question is the algorithm used in the certificates that you issue. Think of it this way: if SHA1 is attackable in trust anchors, a smart attacker will look at the NSS pile-o-anchors and pick the one with the greatest value to attack. If that's not you, you're probably safe. >NSS supports them all, IINM. Not sure about other products though. ...and that's exactly the point. If you use a signature algorithm that is not supported by all the relying parties you care about, then those that don't support it will label your trust anchor as unusable. > >> * key usage: >> + keyCertSign and cRLSign only >> + are these obligatory or optional? >> * CA Key ID and Identifier >> + any contstraints? > >Roots should have a Subject Key ID (SKID), not an Authority Key ID (AKID). >In non-root certs, AKIDs may contain the SKID value of the issuer's cert, >or the issuer name and serial number in the issuer's cert, or both. >Including the Issuer's Issuer Name and serial number is usually a mistake, >but not always. Yep. > >> * Maximum number of intermediate CAs: >> + any constraints? >> + seems like most say "unlimited" > >Roots are not generally constrained. They tend to constrain subordinates. Planning this for the lifetime of your trust anchor is an, er, interesting task. > > Oddities include: >> >> * logotype ? >> + constraints? >> * where to put branding or advertising messages? >> + some use OU >> + Netscape Certificate Comment - outdated? > >Display and use of such stuff is not yet standardized across browsers. >I think most browsers just ignore all that stuff. Advertising does not >belong in subject names of End Entity (leaf) certs. It also does not belong in the trust anchor. Using it will surely cause more confusion than value given that the display is not standardized. Take a look at the display or the trust anchors in IE for XP, and you will see humorous and unreadable names. >All this stuff is documented in the standards, but typical OpenSSL users >never read those. Any competent CA should have lots of people who are >thoroughly familiar with RFC 3280 and RFC 5280. It should be a "core >competence" for all but the janitors. ...but isn't. > > * what is the document that most people refer to? > >RFC 3280, although it's now obsoleted by RFC 5280. RFC 5280 for the semantics, and RFC 3279/4055 for the algorithms. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
