(Sorry, missed this before sending my last message.) At 8:11 PM +0200 9/23/08, Ian G wrote: >But, either way, the general result seems to be: a top level root >should not generally include an(y) EKU.
Correct. That follows from the RFC. >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.) And often not that. Remember, these rules were devised by people who thought that there would be a single universal database that needed unique and universally-understandable identifiers for each CA. With that design criteria, common sense goes out the window. >The curiosity here is that the Certificate Policies extension may >not be shown prominently by software. Nor should it be. Remember that the policy there is most correctly represented by an OID, which is meaningless to end users. >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. Those are not legal notices: they are advertising. You cannot put your whole CP into a field in a cert. >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? One thing that you have missed is that some programs expect that a root with a particular signature algorithm will only issue certs for keys that use that algorithm. Those programs are wrong, but they're out there. Thus, if you use RSA-with-SHA1, some programs will balk when verifying to that root from a cert using, say, RSA-with-SHA256. >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". That is not what "NIST shows". Table 4 of SP 800-57 part 1 says L=3072, and you can assume that is not a typo. Note, however, that that is in a column for DSA and DH, not RSA. > > 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 :) But is not as good of a reference. Understanding SP 800-57 is probably just as valuable as understanding RFC 5280, if not more so. --Paul Hoffman _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
