On Mon, Apr 28, 2014 at 4:29 PM, Erwann Abalea <eaba...@gmail.com> wrote:
> I know DER tools is only a decoder, and from > https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921the > construction of the request makes heavy use of hex magic to build a > request. > Right. OCSP requests are the only thing we *encode* in ASN.1 and so it would be overkill to write a generic ASN.1 DER encoding library . > Quick bug: on the same function, line 945, the test against > issuerCert->serialNumber.len should be against cert->serialNumber.len > instead.. > Thanks for this bug report. David Keeler already filed a bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1002814 if you like money I suggest you read https://blog.mozilla.org/security/2014/04/24/10000-security-bug-bounty-for-certificate-verification/and follow the directions. > Logic at > https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#107doesn'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. > The mozilla::pkix code is NOT intended to be a complete implementation of RFC 5280 and friends. Regarding certificate policy processing in particular, the *entire* purpose of mozilla::pkix's certificate policy support is the determination of whether to show the green site identity block in a browser's address bar. We (I) specifically omitted any part of certificate policy processing that is unnecessary for that purpose. As I said in another thread, I'm hoping we will create a new, much-simplified WebPKI profile of X.509 based on what we learn from mozilla::pkix: no policy mapping, no policy constraints extension (mozilla::pkix enforces requireExplicitPolicy=true and inhibitPolicyMapping=true at all times anyway), no CRLs, etc. > 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). > Thanks. This is a known issue; see https://bugzilla.mozilla.org/show_bug.cgi?id=926265. Interestingly, we've not encountered any websites that are negatively affected by this bug yet. Perhaps we will be able to remove the special cases for self-issued certificates in the WebPKI profile. > 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). > We do intend for mozilla::pkix to enforce the EKU extension in intermediates in the way that we pushed for (and which we understand that Microsoft's implementation also enforces). We do not support anyExtendedKeyUsage and the NSS code we were using before did not support it either. See https://bugzilla.mozilla.org/show_bug.cgi?id=970750 (for mozilla::pkix) and https://bugzilla.mozilla.org/show_bug.cgi?id=279845 (for NSS). Since NSS has been working fine for at least one decade without support for anyExtendedKeyUsage, we can almost definitely omit anyExtendedKeyUsage from the WebPKI profile of X.509. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
