Bonjour,
> Le 17 nov. 2016 à 16:24, Gervase Markham via Public <[email protected]> a > écrit : > > On 17/11/16 14:54, Doug Beattie wrote: >> [DB] Yes, I think it does. You might want to define what "cert data" >> is so we what "non-cert data" is. I'm assuming Cert data consists of >> certificates, CRLs and OCSP responses, nothing else. > > My definition was that cert data is, er, certs, and non-cert data is > everything else, including CRLs and OCSP. Does that make the following > problematic? > > "If you want to sign something that's not a certificate, you have to do > the signing with a cert that has a Basic Constraints extension with a > value of false in the cA component. » This results in the situation where a {BC:cA=True, keyUsage=keyCertSign+keyCrlSign} certificate would be denied the right to sign a CRL. Same reasoning with an OCSP response (signed by the CA itself). > >> Yes, sorry, I mis-spoke. What I think I mean is that existing >> intermediates certs that fit the profile can continue to be used, but >> you have to stop using those which don't, and mint new intermediates >> with new keys to replace them. In other words, rotate your >> intermediates. You can't reuse the same keys because, you are right, >> that doesn't help, as the SHA-1 signatures could still be transferred >> and used with the old intermediate which has the same key. If we do >> it this way, you don't have to revoke the old ones, you just have to >> stop signing SHA-1 things with them. So existing systems continue to >> work. >> >> [DB] What's driving this change now, especially given that SHA-1 SSL >> certificates won’t be trusted by the time this requirement is >> enforced? This is going to be a lot of work for CAs to re-cut all of >> the CAs (shared and dedicated ones for customers). Even if someone >> could get an SSL certificate from one of these CAs, it would be of >> minimal use. Specifying this requirement for new CAs is fine. > > Firstly, it's not just about SSL - Mozilla's policy also covers S/MIME. > > Let's say someone signs an email cert from an intermediate without > pathlen:0. If there's a collision, that signature can be passed to an > intermediate cert which can sign email certs for any email address. But > if it has a pathlen, they can only create an EE cert. An attacker could collide and generate a self-issued CA certificate, again with BC:pathLenConstraint=0 (this is valid). Cordialement, Erwann Abalea _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
