Paul Hoffman wrote: > At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote: >> 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.
A cert with no EKU extension is understood to be valid for all the possible usages (except for a very few). An EKU extension is restrictive. It doesn't say "The cert is ALSO ADDITIONALLY good for these usages". It says "the cert is not good for any usages other than these". When the restrictive extension is absent, the cert is unconstrained with respect to usages. There are a very few usages that are exceptions to that rule. One of them is the EKU for delegated OCSP responders. A delegated OCSP responder's cert MUST have an EKU extension and it must bear the id-kp-OCSPSigning usage OID defined in RFC 2560. A cert that does not bear that OID in an EKU extension cannot be used as a delegated OCSP responder. > 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. Yeah, I agree with that. > Ian: are you saying that Firefox and Thunderbird show different > fields for the names of root certs? Let me field that question, not speaking for Ian obviously. FF and TB share a common cert viewer. It shows a summary tab and a details tab. The summary tab shows a subset of the cert's info, and it's the same subset for all certs. But FF and TB show info taken from certs in other contexts (other windows). For example, FF shows info about the organization behind an SSL server cert in the browser window of an https page (with EV certs only, IIRC). These displays are not meant to show the whole cert, but only to supply the bare minimum info of "who signed this". It's likely that they display different subsets of the cert for those displays. >>> * 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? I think it's just to provide relying parties a way (not necessarily secure) to contact the CA, for support purposes (or sales :) > 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? I agree with those suggestions. >> 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. If that were true, then the table would not supply minimum key sizes for DSA, RSA and ECDSA. But the table does, in fact, supply those sizes, and associates them with different retention periods. The page says: "The algorithms and key sizes in the table are considered appropriate for the protection of data during the given time periods." It does not say that the table applies only to symmetric algorithms. > 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. I agree with that, up to a point. But by that logic, the world of SSL would still all be using SSL2 with 40-bit ciphers, because for many years, those were the only ones universally supported by all browsers. There also products today that cannot handle SHA-2 hashes, and that limit RSA key/signature sizes to 2k bits. I would not advise any CA to limit itself to those limits just for those few straggling products. Much as I don't like to say it, the big question is: does MSIE support it? If IE and FF both support SHA-2, then go for it. If users say "I have to switch away from <favorite browser> to MSIE to shop at site xxx.com", you can be sure that other products will play catch-up, quickly. >> 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. I'm reminded of the janitor in the Dilbert cartoon series, who is the most technically competent employee in the whole company. Maybe I should have written "for all employees, including janitors". :) >> > * 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. That SHOULD BE what "most people refer to', but isn't, alas. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
