At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote: >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.
Completely true for end-entity certificates. But we are talking about root certificates here. I do not find any words in RFC 5280 to support the interpretation that "a set of EKUs in a CA cert means that that CA can only issue certs that also contain one or more from that set". I could be wrong (this stuff is described in different places in the document), but I just don't see it yet. > >>> * 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 :) Oh, please, no. Not in an email-denoted slot. In free text somewhere, maybe, but not in an email slot.... > >> 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. We are splitting hairs here, something that I'm getting bad at with respect to this document. > > 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. Actually, what you say supports what I said. At some point, you decide to ignore the people who can only use the old stuff and move forwards. But that choice is always painful. >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. I think it is the opposite. Last I heard, MSIE didn't support RSA-with-SHA256 on XP but did on Vista. I heard conflicting stories about Microsoft's intention to fix that in an XP upgrade. Others on this list certainly know more about this than I do (and may even be able to test it). _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
