Bonjour Kyle, Le mardi 29 avril 2014 01:10:19 UTC+2, Kyle Hamilton a écrit : > On Fri, Apr 25, 2014 at 6:59 AM, Erwann Abalea <eaba...@gmail.com> wrote: > > Le vendredi 25 avril 2014 13:46:51 UTC+2, Martin Paljak a écrit : > >> On Thu, Apr 24, 2014 at 9:07 PM, Kathleen Wilson <kwil...@mozilla.com> > wrote: > >> > Also, we added a section to the wiki page to list some behavior > changes that > >> > could cause a website certificate to no longer validate with Firefox > 31. > >> > > https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes > >> > >> What is the rationale for this: > >> > >> 4. Mozilla::pkix performs chaining based on issuer name alone, and > >> does not require that issuer's subject key match the authority key > >> info (AKI) extension in the certificate. Classic verification enforces > >> the AKI restriction. > > > > AKI is only a helper for certificate path building. > > It's mandatory for CAs to issue certificates with matching keyIdentifiers > (issued.AKI.keyIdentifier = issuer.SKI), but it's not mandatory for relying > parties to verify that the values match. > > Erwann (and all), > > AKI is necessary for multiple public keys used by the same Subject > certifier. It's particularly useful for a "rolling chain" of public keys, > each one used to sign certificates within a given period of months, but > with overlapping validity periods. > > 0 3 6 9 12 15 18 21 24 27 > |uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|.....|.....|.....| > |.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|.....|.....| > |.....|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....|.....| > |.....|.....|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv|.....| > |.....|.....|.....|.....|uuuuu|vvvvv|vvvvv|vvvvv|vvvvv| > > In this diagram, 'u' means "in use". 'v' means "valid". The numbers at > the top refer to 'counted months'. So, in this case, the private keys are > used for 3 months while their issued certificates are valid for up to 12 > months. There are 5 potential keys, identifiable only through the use of > the AKID extension.
The chain builder can test all possible issuers until it finds a valid one (that's what OpenSSL does, for example). The AKI is only here to say "pssst, this is most probably the certificate you should try first". There's another missing check on the new PKIX lib, PrivateKeyUsagePeriod extension. It's been declared as deprecated in RFC2459 and 3280, isn't mentioned anymore in RFC5280, but it's still defined in X.509, and used on some places, such as CSCA (e-passports, where CA renewal with rekey also happen on a regular basis). > Yes, the certified entity is supposed to provide its verifiable chain, back > to the root (but not including the root)... at least, according to TLS, and > other IETF Security working-area client protocols. But, it's not mandatory > per PKIX, and it's also not mandatory per X.509, either. I agree, it's not mandatory at all. And even if a bunch of certificates is sent along the EE cert, the RP is supposed to take them as potential candidates for its chain building algorithm. Potential candidates only. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
