Ian G wrote: > Nelson B Bolyard wrote: > 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....
For PKI to work with ordinary mom-N-pop users, there must be a small set of claims common to all CAs honored by a browser. Mom-n-pop are less likely to read CPS than they are to read click-through EULAs, even if those CPSs are right there for them to read (as EULA text usually is). So, I think that, realistically, CPS info in a cert is a waste of time. Mom-n-Pop trust that Mozilla has not included any CAs whose CPSs are absurd. Someone with more savvy won't base his decision on the tiny summary in the cert, but will read the whole CPS. Regarding choice of hash in the signature in a root CA cert, I will add that NSS doesn't even check the signature on a trusted root CA cert. The fact that the cert is marked trusted (if it is) tells NSS to use that cert's public key without verifying the signature. So, the signature on the root cert is superfluous ... to NSS. Dunno about other libraries. >> 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 :) I don't know if the tables at keylength.net are equivalent to NIST's or not. There are lots of groups (including some with real cryptographers :) that have published their own tables for this purpose, tables that do NOT have equivalent values to NIST's. Some of them include tables with time resolutions in single years, not in decades (like NIST's), which some CAs find desirable. Many of these tables are less strict than NIST's, allowing shorter keys to be used longer than NIST's tables allow. :( In finality, you have to pick a table from someone you believe has done a really good job of analyzing it. Given that NIST's tables are the basis for the US Government's protection of its own secrets, which it guards jealously, I'm inclined to accept them as adequately conservative. :) > OK. Logic above. That applies to the root though, less so than to > any sig on a cert. >> 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. Ian, I suspect (guess) from the way you use the word cert above, that you use it to mean End Entity cert, as opposed to CA cert. My statement above, about the placement of AIA extensions, was not limited to EE certs. It applies to all certs, EEs and intermediate CAs. In *any* cert, information about how to find the cert of its issuer, and the revocation information from its issuer, may be contained in that cert's AIA extension. Roots don't need that info, however, since a) the root is its own signer, and b) if a root cert was listed in its own CRL, would you believe it? If a CRL, signed by a root, said "Everything this root tells you is a lie" ... what could you conclude from it? >> 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. My perspective is: any CA that says "we don't need to know the standards" and hence "makes it up as they go" does not belong in Mozilla's root list. Unfortunately, in the past, that attitude was conveyed by one or more representatives of a certain CA. I hope that, going forward, that attitude will be noticeably absent in all root cert inclusion requests. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
