Bonjour, Le lundi 28 avril 2014 18:11:30 UTC+2, David Keeler a écrit : > On 04/26/2014 01:44 AM, Erwann Abalea wrote: > > > Took a quick look at the code, it looks like KU/EKU checks is ok, > > BasicConstraints checks are weirdly done, NameConstraints checks are hard > > to follow, CertificatePolicies checks is a joke. I now notice that I didn't > > see date checks (I may have missed it). Init part of the validation code > > follows RFC5280 algorithm, but that's all. > > Revocation checking is done by OCSP only. > > And there's a LOT of magic values everywhere; I noticed them first for OID > > comparisons, but there's little to no use of an ASN.1/DER parser (IIRC, > > there's already 2 implementations in NSS). > > Erwann, > > It would be a great help if you could either expand on the issues you > found here or file bugs in bugzilla. The sooner we catch and deal with > issues the better. > > Date checks are done here: > https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#29 > There's a minimal DER decoder here: > https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixder.h > that implements what is needed for this library and nothing more (for > example, > https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp > makes heavy use of it).
I know DER tools is only a decoder, and from https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921 the construction of the request makes heavy use of hex magic to build a request. Quick bug: on the same function, line 945, the test against issuerCert->serialNumber.len should be against cert->serialNumber.len instead. Logic at https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#107 doesn't follow RFC5280 algorithm, and will probably fail with FBCA and other large cross-certification constructions such as CertiPath (I'm sure they use PolicyMappings, they may use PolicyConstraints, it has slipped off my memory). Current code is sufficient for webPKI, even EV. The normalized algorithms are clearly a torture to read (both X.509 and RFC5280, logic is slightly different but the result is identical), but it's necessary. Same file, #229 (CheckBasicConstraints) doesn't take into account potential self-issued certificates in the chain (they don't account for a "level" in the pathLenConstraint). Same file, #370 (CheckExtendedKeyUsage), if encodedEKUs is NULL and a requiredEKU is asked for, it ends with a success. If encodedEKUs is present and contains the anyExtendedKeyUsage OID, it isn't recognized as valid. And I'm not sure it allows full support for technically constrained CAs (this is done with EKUs used as constraints, which is contrary to X.509/RFC5280, but it was pushed by Mozilla). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
