On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea <eaba...@gmail.com> wrote:
> 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". > Right. We need to measure whether our lack of support for AKI/SKI, which causes us to do such a brute-force search, actually causes real-world performance concerns. I am hoping that it doesn't matter so that we can remove AKI/SKI from the WebPKI X.509 profile. 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). > CSCA is out of scope for mozilla::pkix, at least at this time. More generally, PrivateKeyUsagePeriodand other deprecated features, including *all* of the proprietary Netscape/NSS extensions like "Netscape Cert Type," are also out of scope. Note that new features like the Must-Staple extension *are* within scope and can/should/will be added. > 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. > Exactly. (In the code, the candidate issuer is called potentialIssuer.) Thanks for looking so closely at the code. Please let me know if you have any questions that would help with your investigation of it. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
