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.
Thanks! This has cleared up a few of my questions at least. For what it is worth, I have knocked up a starter set of notes here: https://wiki.mozilla.org/CA:Recommendations_for_Roots feel free to replace the lot :) >> * 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. > > 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. > > 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. OK, thanks. I think Microsoft says something similar; in that they seem to suggest that they set the EKUs (not clear to me how) and they put great stress on the audit covering all of the possible EKUs. http://technet.microsoft.com/en-gb/library/cc751157.aspx But, either way, the general result seems to be: a top level root should not generally include an(y) EKU. >> * 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. 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.) OK. That looks mostly for the EE certs, so I guess there are "no constraints" for the root. (Other than some sort of common sense.) >> * 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. OK! The curiosity here is that the Certificate Policies extension may not be shown prominently by software. As the point of the cert is to make some claim to the user, and the essence of that claim is somehow pertinent to the user's choice, it is understandable that issuers have been frustrated in the past by lack of display of the nature of the claim.... And have therefore chosen to place their legal notices in the OU. I personally don't like it, but I can understand the frustrations. >> * 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. > > There are two different name attributes that have historically been used > for email addresses. Each attribute has an OID that officially defines > it, and a name, and some have a "short name" such as E=, CN= etc. > The historical email address attributes in a subject name were: > > Short Defined Formal Full OID > Name In Name > ----- -------- ---------------- -------------------------- > MAIL RFC 1274 id-rfc822Mailbox 0.9.2342.19200300.100.1.3 > E RFC 2985 emailAddress 1.3.6.1.4.1.1466.115.121.1.26 > > RFC 3280 and RFC 5280 recognize the use of the deprecated emailAddress > attribute for legacy applications, but mandate the use of Subject > Alternative Name extensions. They do not even recognize the older > attribute from RFC 1274. NSS recognizes both, and also supports > the Subject Alternative Name, which is preferred. OK. This use of a support email address for a root is not a terrifically important one ... so if they want to do that, then following the recommendatons for subjectAltName seems non-controversial. >> 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. Hmm, here we have to use an RSA self-sig over a hash over the RSA public key. Check my logic: the hash on the key is protected by: a. being a fixed hash over a fixed key, so 160 bits of strength (birthday attacks do not apply) b. the public key verifies the digital signature, so any attack on any one element has to also match the other two (which would not be true if this were a cert). b. publication in root list, the hashing and self-signing is not as important as it would be with a (real) certificate So given that, the hash on the root is unimportant, and SHA1 should be fine. Or have I missed something? Then, for the RSA size, it seems that 4096 is the current viewpoint of what is good for around 30 years. Microsoft has put a limit of 2048 as minimum, NIST shows that as "good for 2011 -> 2030". > 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 Ah, good point. http://keylength.net/ might be easier to read :) >> * 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. > >> * format is PKCS1, Hashes are SHA1 >> + any chance of SHA-256? > > SHA1 is definitely incongruent with a 4k key size. > NSS supports them all, IINM. Not sure about other products though. OK. Logic above. That applies to the root though, less so than to any sig on a cert. >> * key usage: >> + keyCertSign and cRLSign only >> + are these obligatory or optional? >From rfc 5280, this is obligatory for a root, it seems. >> * 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. Thanks, this one is reasonably well explained now that I've read it in 5280. >> * Maximum number of intermediate CAs: >> + any constraints? >> + seems like most say "unlimited" > > Roots are not generally constrained. They tend to constrain subordinates. OK, reviewed that one. >> 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. > >> Things that are uncertain but are probably documented somewhere: >> >> * AIA hint for intermediates go in the root or the certs? > > An AIA extension in a cert is a hint on how to find the cert or the OCSP > responder for the issuer of that cert. OK, certs only. It does seem rather odd that such things as checks on certificates were not in for example the subroots... but, no problem. >> * OCSP and CRL URLs go in the root or the intermediates or certs? > > URLs in a cert provide hints about how to get additional info that will > be used in validating that cert. OK, certs. >> Random questions: >> >> * What's missing? What is in emerging practice but is not >> documented anywhere? > > Do You mean, not documented in any "How to use OpenSSL web pages"? Ah, another for the list, thanks. > 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. :) I have another perspective: "if it is not written down by you (the CA) it doesn't exist." Standards can be useful, but a bit unfulfilling in this field. >> * What about all these old Netscape fields, are they replaced or >> still current? >> + Netscape Certificate Comment >> + Netscape Certificate Type >> + Netscape Certificate Authority Policy URL >> + Netscape Certificate Authority Revocation URL > > Netscape Cert Type is still supported by NSS. It is NEVER necessary. > The KU and EKU extensions have obviated it. If both a Netscape Cert > Type and those other extensions are present, NSS will honor the union > of the capabilities they present. > > The other Netscape extensions are not used (other than to be displayed > when viewing the cert) and never were. They're all comments. OK, thanks! >> * what is the document that most people refer to? > > RFC 3280, although it's now obsoleted by RFC 5280. Thanks! iang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
