Re: Checking certificate requirements
On Wed, May 28, 2014 at 4:42 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: Whether it's version 1 or 3 has no effect on path building. If the policy does require this, it's largely for cosmetic reasons than any strong technical reasons. That said, cutting a new v3 root may involve bringing the root signing key out of storage, hoisting a signing ceremony, etc. It may not be worth the cost. NSS could, if it wanted, create dummy certs (with invalid signatures) that looked just like the real thing, and things 'should' just work (mod, you know, the inevitable avalanche of bugs that crop up when I make statements like this). mozilla::pkix will not trust a v1 certificate as an intermediate CA, but it does accept v1 root certificates for backward compatibility with NSS and for the reasons Ryan mentioned. v1 TLS end-entity certificates do not comply with our policy because a v1 certificate cannot (according to the spec) contain a subjectAltName extension and we require all TLS end-entity certificates to contain subjectAltName. Similarly, v1 certificates cannot legally contain an OCSP responder URI which is also required (practically). Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Checking certificate requirements
On Fri, May 23, 2014 at 11:00:17AM +0200, Matthias Hunstock wrote: Am 22.05.2014 22:52, schrieb Kurt Roeckx: So I've added some other strange looking graph about the 39 and 60 month limit in the BR. In the section Certificate valid longer than 39 months you state that According to CA/B forum baseline requirement in section 9.4.1 only in special cases can it be longer than 39 months. However, in the CA/B BR this limit has a starting date of 1 April 2015: Except as provided for below, Subscriber Certificates issued after 1 April 2015 MUST have a Validity Period no greater than 39 months So it is not THAT strange ;) With strange I meant valid from starts at 100% and the valid to stop at 100%. Which is very logical because of the periods I draw and from when I got certificates, and it's not how the other graphs look. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Checking certificate requirements
Thanks, Kurt, for sharing! m...@chemalogo.com +34 666 429 224 (Spain) gplus.to/chemalogo @chemalogo https://twitter.com/chemalogo/ www.linkedin.com/in/chemalogo Skype: chemalogo On Tue, May 20, 2014 at 7:03 PM, Kurt Roeckx k...@roeckx.be wrote: I've been working on checking that certificates made by the CAs are following requirements, and how it changes over time. You can see the results at: http://www.roeckx.be/certificates/ Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Checking certificate requirements
On Tue, May 20, 2014 at 11:23:54AM -0700, Kathleen Wilson wrote: Maybe we should re-visit the idea of a wall of shame, and publicly list the CAs who are still issuing certificates with the following problems. * No Subject alternative name extension * Fails decoding the character set * Contains control characters * Certificate not version 3 * Long-lived certs (beyond what BRs allow) So I've added some other strange looking graph about the 39 and 60 month limit in the BR. I would actually like to add to that list those certificates that fail to parse. Those are certificates that pass the sign verification step but then fail to parse for some reason. But I really should take a closer look at why some of them fail. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Checking certificate requirements
I've been working on checking that certificates made by the CAs are following requirements, and how it changes over time. You can see the results at: http://www.roeckx.be/certificates/ Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Checking certificate requirements
Cool. It's good to see that the number of certs with these issues has declined significantly, especially considering the valid from date. Have you emailed the CAs issuing these certs to let them know they might have issuance issues? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kurt Roeckx Sent: Tuesday, May 20, 2014 11:03 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Checking certificate requirements I've been working on checking that certificates made by the CAs are following requirements, and how it changes over time. You can see the results at: http://www.roeckx.be/certificates/ Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Checking certificate requirements
On 5/20/14, 10:03 AM, Kurt Roeckx wrote: I've been working on checking that certificates made by the CAs are following requirements, and how it changes over time. You can see the results at: http://www.roeckx.be/certificates/ Kurt Kurt, Great work! Thank you for sharing this analysis! Conclusions Some of CA/Browser forum baseline requirements seems to be getting adopted good, but there are still some certificates generated that don't follow the requirements. Other requirements don't seem to get adopted. Those that don't get adopted seem to have to do with things about the CA itself and not with subject of the certificates. Maybe we should re-visit the idea of a wall of shame, and publicly list the CAs who are still issuing certificates with the following problems. * No Subject alternative name extension * Fails decoding the character set * Contains control characters * Certificate not version 3 * Long-lived certs (beyond what BRs allow) There is a surprising amount of long lived certificates. This results in it taking a long time to get those requirements adopted. Yep. Long-lived certs are definitely a problem. It's also impeded phasing out 1024-bit certs. News May 2013: I've been contacting CAs about the missing subject alternative name extension, since I think that's currently the biggest problem. Hopefully we'll see things improve over time. Thank you for doing that! How has it been going? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Checking certificate requirements
I saw that he's contacting CAs about the missing SANs, but what about the other issues? I'd be very interested in hearing about any non-compliant certs related to DigiCert (if there are any). Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Tuesday, May 20, 2014 12:24 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Checking certificate requirements On 5/20/14, 10:03 AM, Kurt Roeckx wrote: I've been working on checking that certificates made by the CAs are following requirements, and how it changes over time. You can see the results at: http://www.roeckx.be/certificates/ Kurt Kurt, Great work! Thank you for sharing this analysis! Conclusions Some of CA/Browser forum baseline requirements seems to be getting adopted good, but there are still some certificates generated that don't follow the requirements. Other requirements don't seem to get adopted. Those that don't get adopted seem to have to do with things about the CA itself and not with subject of the certificates. Maybe we should re-visit the idea of a wall of shame, and publicly list the CAs who are still issuing certificates with the following problems. * No Subject alternative name extension * Fails decoding the character set * Contains control characters * Certificate not version 3 * Long-lived certs (beyond what BRs allow) There is a surprising amount of long lived certificates. This results in it taking a long time to get those requirements adopted. Yep. Long-lived certs are definitely a problem. It's also impeded phasing out 1024-bit certs. News May 2013: I've been contacting CAs about the missing subject alternative name extension, since I think that's currently the biggest problem. Hopefully we'll see things improve over time. Thank you for doing that! How has it been going? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Checking certificate requirements
On 5/20/14, 12:32 PM, Kurt Roeckx wrote: On Tue, May 20, 2014 at 11:23:54AM -0700, Kathleen Wilson wrote: On 5/20/14, 10:03 AM, Kurt Roeckx wrote: Conclusions Some of CA/Browser forum baseline requirements seems to be getting adopted good, but there are still some certificates generated that don't follow the requirements. Other requirements don't seem to get adopted. Those that don't get adopted seem to have to do with things about the CA itself and not with subject of the certificates. Maybe we should re-visit the idea of a wall of shame, and publicly list the CAs who are still issuing certificates with the following problems. I'm not sure how I feel about the wall of shame. News May 2013: I've been contacting CAs about the missing subject alternative name extension, since I think that's currently the biggest problem. Hopefully we'll see things improve over time. Thank you for doing that! How has it been going? I've actually didn't get any reply from the CAs (that are in the mozilla program) so far. I guess we'll have to wait and see. Kurt Another approach is to file a Bugzilla bug for each CA who is issuing new certs with the problems Mozilla cares about (i.e. the things I listed). You can file the bug as https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.orgcomponent=CA%20Certificates The bug will get assigned to me, and I can add the corresponding CA person to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Checking certificate requirements
On Tue, May 20, 2014 at 12:31:14PM -0600, Jeremy Rowley wrote: I saw that he's contacting CAs about the missing SANs, but what about the other issues? I'd be very interested in hearing about any non-compliant certs related to DigiCert (if there are any). Running a query on all issuers with DigiCert somewhere in the name for certificates generated since February I see no error for any of my tests. (I see 7 issuers.) If I look starting from May 2013 I see 22 with a missing SAN, 2 with invalid encoding, 1 with non-printable charcaters over 16 issuers. If you want I can send examples. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Checking certificate requirements
Please do! -Original Message- From: Kurt Roeckx [mailto:k...@roeckx.be] Sent: Tuesday, May 20, 2014 2:22 PM To: Jeremy Rowley Cc: 'Kathleen Wilson'; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Checking certificate requirements On Tue, May 20, 2014 at 12:31:14PM -0600, Jeremy Rowley wrote: I saw that he's contacting CAs about the missing SANs, but what about the other issues? I'd be very interested in hearing about any non-compliant certs related to DigiCert (if there are any). Running a query on all issuers with DigiCert somewhere in the name for certificates generated since February I see no error for any of my tests. (I see 7 issuers.) If I look starting from May 2013 I see 22 with a missing SAN, 2 with invalid encoding, 1 with non-printable charcaters over 16 issuers. If you want I can send examples. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
