Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Thu, Aug 10, 2017 at 11:34 AM, identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > We acknowledge seeing this issue and are looking into it. > Details will be supplied as soon we can but not later that today’s end of > business day. > Thanks for looking

Re: Misissued certificates

On August 10, 2017 at 9:44:01 PM, Jakob Bohm via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: On 11/08/2017 00:29, Jonathan Rudenberg wrote: > >> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >> >> Can anyone

2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

At 11:30am PST on August 10, 2017, Let’s Encrypt was made aware of a compliance issue regarding unicode normalization of domain names. During the same day we were made aware of the issue, all unexpired non-compliant certificates were found and revoked, a fix was applied to our CA systems, and

Re: Certificates with improperly normalized IDNs

On 11/08/2017 00:14, Ryan Sleevi wrote: On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: This raises the question if CAs should be responsible for misissued domain names, or if they should be allowed to issue certificates to

Re: Certificates with improperly normalized IDNs

On 11/08/2017 00:00, Jonathan Rudenberg wrote: On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy wrote: On 10/08/2017 22:22, Jonathan Rudenberg wrote: RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized Domain

Re: Misissued certificates

On 11/08/2017 00:29, Jonathan Rudenberg wrote: On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy wrote: Can anyone point out a real world X.509 framework that gets confused by a redundant pathlen:0 in a CA:FALSE certificate? (Merely to

Re: Certificates with invalidly long serial numbers

On 11/08/2017 00:12, Ryan Sleevi wrote: Could you explain how it benefits Mozilla users to optimize for OV or EV, given that it does not provide any additional security value? Of all the browsers I have tried, Firefox is the one that most aggressively promotes EV certificates, going to the

RE: Certificates with invalidly long serial numbers

I disagree - 24 hours is enough to reissue the certificate, but 24 hours usually isn't enough to contact the subscriber, regardless of cert type. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf

Re: Certificates with improperly normalized IDNs

On Thu, Aug 10, 2017 at 2:31 PM, Jakob Bohm via dev-security-policy wrote: > On 10/08/2017 22:22, Jonathan Rudenberg wrote: >> >> RFC 5280 section 7.2 and the associated IDNA RFC requires that >> Internationalized Domain Names are normalized before encoding

RE: Certificates with metadata-only subject fields

A couple of people also pointed out that we previously discussed these exact certs here: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/DgeLqKMzId s/E9--gj5WEAAJ The decision then was that we should prevent further issuance of certs with N/A and other metadata but that

RE: Certificates with invalidly long serial numbers

Not really - most CAs reuse validation information for the time period specified under the BRs, which is currently 825 days under section 4.2.1. The hardest part of the whole process is typically contacting the customer to start the replacement process. The problem is probably worse for fully

Re: TrustCor root inclusion request

Greetings, I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the following notes: *CP* (http://www.trustcor.ca/resources/cp.pdf) 1.6.3 1.6.4 Nit: Section 1.1 says that "Sections which do not apply to TrustCor CA, or where TrustCor CA makes no authoritative statement, will

Re: Misissued certificates

> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy > wrote: > > Can anyone point out a real world X.509 framework that gets confused by > a redundant pathlen:0 in a CA:FALSE certificate? (Merely to assess the > seriousness of the issue,

Re: Certificates with improperly normalized IDNs

On Thu, Aug 10, 2017 at 5:31 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > This raises the question if CAs should be responsible for misissued > domain names, or if they should be allowed to issue certificates to > actually existing DNS names. > No. It

Re: Certificates with invalidly long serial numbers

Could you explain how it benefits Mozilla users to optimize for OV or EV, given that it does not provide any additional security value? It seems far better for the security of users, and the ecosystem, to have such certificates revoked in 24 hours. If the subscriber's selection of certificate

Re: Certificates with improperly normalized IDNs

> On Aug 10, 2017, at 17:31, Jakob Bohm via dev-security-policy > wrote: > > On 10/08/2017 22:22, Jonathan Rudenberg wrote: >> RFC 5280 section 7.2 and the associated IDNA RFC requires that >> Internationalized Domain Names are normalized before encoding

Re: Certificates with improperly normalized IDNs

We are aware of this and are looking into it further. On 08/10/2017 01:22 PM, Jonathan Rudenberg via dev-security-policy wrote: > RFC 5280 section 7.2 and the associated IDNA RFC requires that > Internationalized Domain Names are normalized before encoding to punycode. > > Let’s Encrypt appears

Re: Certificates with invalidly long serial numbers

But that would require the issuer of the replacement cert (which might not be a fast-issue DV cert) to complete validation in something like 36 hours, which is much shorter than the normal time taken to do proper OV and/or EV validation. I have previously suggested 14 days for live certificates

Re: Certificates with improperly normalized IDNs

On 10/08/2017 22:22, Jonathan Rudenberg wrote: RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized Domain Names are normalized before encoding to punycode. Let’s Encrypt appears to have issued at least three certificates that have at least one dnsName without the

Re: Misissued certificates

On Thursday, August 10, 2017 at 12:21:18 PM UTC-4, Ryan Sleevi wrote: > On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote: > > > What's it going to take for

Re: Misissued certificates

On 10/08/2017 20:14, Matthew Hardeman wrote: Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of ev-valid.identrustssl.com It has a normal 2 year validity period. Which again sounds like a certificate administratively created to serve as a test point certificate for the

Certificates with improperly normalized IDNs

RFC 5280 section 7.2 and the associated IDNA RFC requires that Internationalized Domain Names are normalized before encoding to punycode. Let’s Encrypt appears to have issued at least three certificates that have at least one dnsName without the proper Unicode normalization applied.

Fwd: Misissued certificates - pathLenConstraint with CA:FALSE

Forwarding to the right (cert-related) group Forwarded Message Subject: Misissued certificates - pathLenConstraint with CA:FALSE Date: Wed, 9 Aug 2017 19:25:31 -0400 From: Alex Gaynor To: helpd...@identrust.com, dev-secur...@lists.mozilla.org

RE: Certificates with metadata-only subject fields

Thinking about it more, this particular issue is the most annoying one because: 1. There’s not a limited defined set of items that encompass what the OU may include, 2. The OU is generally the dumping ground for information, and 3. There’s no requirement this information is

RE: Misissued certificates

This is interesting. We had one Sub CA who mis-issued some pre-certs but then never issued an actual certificate tied to the pre-certificate. There was a previous Mozilla discussion (link coming) where mis-issuance of a pre-certificate was akin to mis-issuance of the certificate itself. The

RE: Certificates with metadata-only subject fields

Not really – and I don’t object to the certificate problem reports. I greatly appreciate the work Alex and Jonathan are doing. I disagree that finding small issues indicates larger issues as a whole. There’s no support for that claim. It’s just as likely that larger issues are going

Re: Certificates with common names not present in their SANs

CFCA stated this, in https://cabforum.org/pipermail/public/2017-July/011733.html Since then, no further evidence of this claim has been provided. SHECA ( https://cabforum.org/pipermail/public/2017-July/011737.html ) and GDCA ( https://cabforum.org/pipermail/public/2017-July/011736.html ) are

Re: Certificates with less than 64 bits of entropy

On Thursday, August 10, 2017 at 11:27:53 AM UTC-5, Nick Lamb wrote: > The truth is that there is no positive test for randomness, any work in this > area is going to end up needing a judgement call, so I think inconveniencing > the CAs even a small amount with such a policy change just to make

RE: Certificates with metadata-only subject fields

On this particular issue, it's questionable whether these are a violation of a strict reading of the BRs. Section 7.1.4.2.2(i) defines the OU field. Section 7.1.4.2.2(j) defines "Any other subject". Section 7.1.4.2.2(J) : "All other optional attributes, when present within the subject field, MUST

Re: Certificates with metadata-only subject fields

Can you provide an example of what you believe is a bigger issue that has been masked? Otherwise, it sounds like you're saying "Ignore the obvious errors, because maybe someone will find something non-obvious, and we don't want to miss out" - but that's a deeply flawed argument, and I would hope

Re: Certificates with common names not present in their SANs

Didn't someone recently float the argument that the native u-label was required by local regulation / custom (in China) to be included and so they stuffed it into the CN? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

RE: Certificates with metadata-only subject fields

I strongly disagree. The discussion around errors like these masks the bigger issues in the noise. If there are bigger issues, let's find those. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of

Re: Misissued certificates

Similarly, the cert at https://crt.sh/?id=92235998 has SAN dnsName of ev-valid.identrustssl.com It has a normal 2 year validity period. Which again sounds like a certificate administratively created to serve as a test point certificate for the root programs.

Re: Misissued certificates

I don't know whether it was noticed or if it matters to anyone, but I did note that for at least one of these certificates, particularly the one at https://crt.sh/?id=92235996 , that the sole SAN dnsName for the certificate is ev-expired.identrustssl.com. The cert also had a whopping 24 hours

RE: Certificates with less than 64 bits of entropy

Hi Jonathan, InfoCert's sub CA was revoked on August 1, 2017. We'll reach out to Siemens. They moved to Quovadis a while ago and are no longer issuing from that Sub CA. Jeremy -Original Message- From: dev-security-policy

Re: Certificates with common names not present in their SANs

> On Aug 5, 2017, at 17:36, alex.gaynor--- via dev-security-policy > wrote: > > Hi all, > > 7.1.4.2.2 of the CABF Baseline Requirements requires that common names always > be an element from the SAN. > > Here are 62 certs, from a variety of CAs which

Re: Misissued certificates

On Thursday, 10 August 2017 16:55:22 UTC+1, iden...@gmail.com wrote: > certificates contain the issue. Three (3) of these are real certificates; > however, one has expired. We have revoked the other two certificates. The > remaining two (2) are pre-certificates. To clear this up for anybody who

Re: Certificates with less than 64 bits of entropy

On Thursday, 10 August 2017 16:20:56 UTC+1, Jonathan Rudenberg wrote: - Three intermediates, "TeleSec ServerPass Class 2 CA”, "Go Daddy Secure Certificate Authority - G2”, and "Starfield Secure Certificate Authority - G2”, (which are not in this list) appear to issue certificates with serial

Re: Misissued certificates

On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote: > > What's it going to take for mozilla to set up near real-time > > monitoring/auditing of certs showing up in ct

Re: Misissued certificates

Hi IdenTrust, When you say that the remaining two are pre-certificates, are you asserting that no corresponding certificate was ever issued? Or merely that we can't prove one was based on what's in the existing CT logs? Alex On Thu, Aug 10, 2017 at 11:55 AM, identrust--- via dev-security-policy

Re: Misissued certificates

On Thursday, August 10, 2017 at 12:23:55 AM UTC-4, Lee wrote: > What's it going to take for mozilla to set up near real-time > monitoring/auditing of certs showing up in ct logs? > > Lee > > On 8/9/17, Alex Gaynor via dev-security-policy > wrote: > >

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

We´ll talk with the Management and the Certification Audit Body and will give feedback. Arno Am 10.08.2017 um 15:57 schrieb Ryan Sleevi: Under the Baseline Requirements, v1.4.8 (current version), 4.9.1.1, "The CA SHALL revoke a Certificate within 24 hours if one of more of the following

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Wednesday, August 9, 2017 at 11:59:42 PM UTC-4, Lee wrote: > On 8/9/17, Eric Mill wrote: > > On Wed, Aug 9, 2017 at 4:28 PM, Lee wrote: > > > >> On 8/9/17, Eric Mill via dev-security-policy > >> wrote: > >> > On Tue,

Re: Certificates with less than 64 bits of entropy

> On Aug 10, 2017, at 11:20, Jonathan Rudenberg via dev-security-policy > wrote: > > QuoVadis (560) >Siemens Issuing CA Internet Server 2016 (560) > > D-TRUST (224) >D-TRUST SSL Class 3 CA 1 2009 (178) >D-TRUST SSL Class 3 CA 1 EV 2009 (45) >

Certificates with less than 64 bits of entropy

Baseline Requirements section 7.1 says: > Effective September 30, 2016, CAs SHALL generate non‐sequential Certificate > serial numbers greater than zero (0) containing at least 64 bits of output > from a CSPRNG. There are 1027 unexpired unrevoked certificates known to CT with a notBefore date

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

> On Aug 10, 2017, at 07:55, Fiedler, Arno via dev-security-policy > wrote: > > Hello Jonathan, > > the certificate has 64 bits of entropy in the "DNqualifier" field instead of > the serial number field. > > Since 2012 we used this way of adding

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

Under the Baseline Requirements, v1.4.8 (current version), 4.9.1.1, "The CA SHALL revoke a Certificate within 24 hours if one of more of the following occurs: 9. The CA is made aware that the Certificate was not issued in accordance with these requirements or the CA's Certificate Policy or

Re: Certificates with metadata-only subject fields

As a friend of mine sagely points out, fundamentally the current incentives for a CA are, "Issuing certs gets us money, not issuing certs does not get us anything". That's an incentive structure that badly needs correction -- CAs should be accountable for what they issue. Without speaking to

Re: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

Hello Jonathan, this certificate has 64 bits of entropy in the "DNqualifier" field instead of the serial number field. Since 2012 we used this way of adding random bits to certificates to mitigate preimage attacks. From a security perspective the amount of Entropy in the certificate should

AW: Certificate issued by D-TRUST SSL Class 3 CA 1 2009 with short SerialNumber

Hello Jonathan, the certificate has 64 bits of entropy in the "DNqualifier" field instead of the serial number field. Since 2012 we used this way of adding random bits to certificates to mitigate preimage attacks From a security perspective the amount of Entropy in the certificate should be

Re: High traffic on this list, and Mozilla root program involvement

Hi Jeremy, On 09/08/17 21:57, Jeremy Rowley wrote: > I was thinking you should just have the Cas add them all for you. Makes it > easier on you and demonstrates they are tracking and remediating these > issues. If I were going to create a bug for these in Mozilla would you > prefer to see one

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Monday, August 7, 2017 at 3:47:39 PM UTC-5, Jonathan Rudenberg wrote: > “IdenTrust ACES CA 2” has issued five certificates with an OCSP responder URL > that has a HTTPS URI scheme. This is not valid, the OCSP responder URI is > required to have the plaintext HTTP scheme according to Baseline

Re: Certificates with invalidly long serial numbers

The answers from CAs we typically see in this group are more along the lines of not thinking it necessary to revoke at all than needing more time, I'd say. So I don't really see what this idea that 24 hours would be too short is based on. I think relaxing the revocation time limit may in fact