On Feb 12, 2008 5:43 AM, Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]> wrote: > > > Hi Kyle, > > I always believe that creative ideas are useful, even if they are not > implementable, because they may lead to something that is. But here my short > reply: > > Kyle Hamilton wrote: >> I am not party to the CAB Forum guidelines, and in fact wouldn't have any >> idea where to find them. That said, though, I would suggest that EV be an >> attribute of the trust anchor (ie, like the SGC attribute used to be in >> older versions of Netscape Navigator). I am not entirely certain it doesn't >> make sense to create a specific magic trust anchor for Mozilla to directly >> create chained certificates from, with a CA depth of 2, and all CAs granted >> EV validation signed by this cert. > > The admittance and upgrade of CA roots to roots that are recognized as EV > enabled is effectively that "trust anchor". Without it, they will remain > just regular CAs or not at all. So NSS is like as if Mozilla has issued the > certificate ;-)
I'm remembering the situation with Netscape Navigator and SGC -- anyone with local access to the cert DB could insert a new CA, and mark it as "SGC capable". That was basically to increase the strength of encryption available from 40 bits to 128 bits during an SSL renegotiation. However, if someone can put an EV cert in and mark it as such, then that arguably causes more security issues for users. Thus, my suggestion that Mozilla create a magic trust anchor to issue EV-certified CAs from. The issue that causes me to want a CA depth of 2 is actually more one of pragmatic security than ideal security. An anchor itself should, as a matter of course, minimize the number of valid signatures that it creates so that it reduces hash collision potential. In order to do this effectively, it should be able to sign sub-CAs for specific date ranges. This reduces the possible depth to 1. I know that if any certificate with a depth of 0 tries to certify any other key, it's a path failure -- and that means that they must be granted the ability to sign host certificates. (This may, in actuality, be something that the CA's CPS would give guidance as to the decision of. If they want to sign host certs directly with their root, they get a depth of 1. If they want to create a date-based sub-CA, they get a depth of 2.) (I know that I am technically misusing the term 'anchor' here. I'm using it, in this case, to refer to 'the key for the CA which has been approved for extended validation' -- even though, under this proposal, the self-signed EV anchor would be the one under MoFo's control. As long as the EV-signed CA key is in the root store as well, I am using the term 'anchor' to describe that as well.) > The problem I'm seeing perhaps is, that once a root is enabled as such it > can currently issue X intermediate CA certificates. Tracking that is > impossible. I don't know if NSS can override the path length which is in the > CA root. But it's an interesting idea ;-) Ah, I see the confusion. I'm specifically suggesting recertifying the public keys provided by the CAs with a specific, magic EV-enabled root under the control of MoFo. (As long as the CA name [Authority Identifier] is the same, and the public key [Authority Key Identifier] is the same, it will not matter if the certificate included in NSS is the self-signed one, or if it is one generated by MoFo from a MoFo EV root.) Under this proposal, the EV root would be under MoFo's control, and thus NSS itself would not need to be extended to override path validation checking. Also under this proposal, the certificate allowing for the CA to be used as EV can be revoked for as long as necessary for them to shape up, and then a new one issued when they do shape up. > This would allow EV validation to be limited to those certs (the path > length constraint would prevent the validated CAs from issuing workable sub > CA certs). That would be correct. Again, I'm just expressing a pragmatic reason to allow a path length of 2 in some circumstances. >> Since the certificate to do this would be in Mozilla Foundation's hands, >> an argument could be made that the normal requirement of a webtrust audit >> would be unneeded (since without it it would be limited to client-modifiable >> flags in the cert db, and the browser vendor is already ultimately-trusted >> anyway). > > Since I believe that overriding the path length isn't possible - and also > not feasible if the same CA root issues also other certificates than EV, the > only way to get some control is, to admit only the subordinated CA and mark > it as EV enabled. It should have path length 0. Path length 1. It needs to be able to create host certs that would have path length 0. > Sounds like a big headache? In the beginning I thought it is, but actually > how many EV enabled sub CAs does a typical CA have? One, maybe two? So the > effort we are investing right now to enable all those roots would be the > same. Just that sub CAs have usually a shorter life time and we'd have to do > that again in ten years perhaps...but that's what control is about. Ideally, I'd like to see EV roots create time-limited rolling CAs -- maybe 2 years in length, certify with it for a year, then after one year create another time-limited CA valid for 2 years, certify with it for only a year... the 2 year lifespan would allow for the expiration of the 1-year certs made by it at the end of the first year. But, that's a CA practice issue. >> Just tossing the possibility out on the table. > Good! Just tossing back :-) -Kyle H _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
