Paul Hoffman wrote: > At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote: >> Ian G wrote, On 2008-09-22 09:45:
>> > * 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. > > 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. Sure, but I took that as "no special constraints" :) > Ian: are you saying that Firefox and Thunderbird show different > fields for the names of root certs? Yes. If you go to some website, with Firefox it shows the O field as the primary or leading Name field. For example http://financialcryptography.com will show: Verified by: Root CA on the transparent dropdown new-fangled customs dude box, and the same thing in the More Info dialog. http://paypal.com/ will show the Verified by: VeriSign, Inc., In each case the the certificate reveals the O= as the field with that info. Then, Thunderbird, if you click on the yellow pen for a signed email, will show: Certificate issued by: CA Cert Signing Authority And the "View Signature Certificate" indicates that this is the CN field of the same root as above. Some comments: CAcert people have tested mostly non-windows stuff and suggest that CN is more popular in this role. FWIW. I added an attachment of Tb's drop-down, but it will probably get stripped on the list. Also note that the claim is distinct. One says "Verified by" and the other says "Certificate issued by" ... the latter is probably a good safe pick in the absence of a proper legally sound framework for browser certificates; the former raises questions about whether there is any basis for that claim :-( Finally, I'm not saying this is a bug. There are many more important bugs than that, such as the (wider) claims issue above, and the fact that the name, claim and claim-maker aren't displayed on the chrome. But this is par for the course. The job right now is not to fix PKI... >>> * 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? Well, support people think it useful. Any real objections? >>> * 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 > > An RSA 4096 is equivalent in strength to about 150 bits, a weird > length. Why not do 3072, which is equivalent to AES-128? I'm not totally with you here. The RSA key that is in the CA root is used for signing other certificates. It doesn't do AES, although the EE cert might be used to do an encryption of an AES session key... Are you saying that the more likely benchmark is an AES-128 and this would imply lowering every other component to suite? This seems perhaps logical, but most of the new TLS suites are moving to AES-256, no? (I write about this sort of comparison in an old paper of mine: http://iang.org/papers/pareto-secure.html which was an attempt to place it on a logical foundation... ) > 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 put some starter ideas over on https://wiki.mozilla.org/CA:Recommendations_for_Roots That might be a good place to make any ECC recommendations. >> > * 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. > > 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. > > Determining the lifetime of a trust anchor key has many aspects. How > strong is the key against the best-known attacks? How likely is it > that someone will copy the private key and use it without you knowing > about it? What is the cost to the organization if there is a > compromise and the key needs to be revoked? Only the first has > practical answers. Sigh. I do fear that you are right; these other attacks are far more of an issue than RSA cracking. When has anyone ever cracked RSA? >>> * format is PKCS1, Hashes are SHA1 >>> + any chance of SHA-256? >> SHA1 is definitely incongruent with a 4k key size. > > ...but still useful because of its wide deployment. For a trust > anchor, you are really only concerned with the preimage strength, not > the collision strength, of the hash algorithm. 160 bits is enough for > anyone for the foreseeable future. The more interesting question is > the algorithm used in the certificates that you issue. > > Think of it this way: if SHA1 is attackable in trust anchors, a smart > attacker will look at the NSS pile-o-anchors and pick the one with > the greatest value to attack. If that's not you, you're probably safe. The tall poppys defence :) ... >>> * Maximum number of intermediate CAs: >>> + any constraints? >>> + seems like most say "unlimited" >> Roots are not generally constrained. They tend to constrain subordinates. > > Planning this for the lifetime of your trust anchor is an, er, > interesting task. Yes, agreed, obvious conundrums here. It seems that the root list authorities have decided to put the stress on the audits to solve this, but this leaves a lot of open questions. I don't really see this declaration as a real solution, but some things resist real solutions, and right now there is little to be done about it. >> > 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. > > It also does not belong in the trust anchor. Where does it belong? OK, drifting back into history, when we were talking about this on a similar list about 3 or 4 years back, I at least was pushing that the root list authority (in this case Mozilla Foundation) would manage a list of roots and capabilities (trust bits?) and also the logos. When a cert was good, it would pop up the logo like a favicon alongside. There is no need for this stuff to all go in the cert itself; it is the root list that is the key resource here. If that is corrupted then everything's turtles, anyway. > Using it will surely > cause more confusion than value given that the display is not > standardized. Take a look at the display or the trust anchors in IE > for XP, and you will see humorous and unreadable names. OK. Another good reason to enable these things under management & negotiation. >> 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 also thought this was a very hopeful thing. Actually I find the premise somewhat odd -- something that people do once every 5 years *maximum* is not a good target for core competence. Recalling that the definition of core competence necessarily implies it is somewhat singular... I'd much rather ask whether a CA had a core competence in converting verified subscriber information into secured certificate claims than something as obscure and unreal as driving OpenSSL in strange and arcane ways? >> > * 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. Thanks, added. iang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
