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. 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. > * 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.) > * 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. > * 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. > 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 > * 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. > * 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. > * Maximum number of intermediate CAs: > + any constraints? > + seems like most say "unlimited" Roots are not generally constrained. They tend to constrain subordinates. > 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. > * 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. > 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"? 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. > * 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. > * what is the document that most people refer to? RFC 3280, although it's now obsoleted by RFC 5280. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
