Re: Symantec Update on SubCA Proposal

> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Devon O'Brien via dev-security-policy > Sent: Wednesday, August 09, 2017 12:24 PM > To: mozilla-dev-security-pol...@lists.mozilla.org >

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

On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote: > IdenTrust is fully aware of the situation and has consulted with internal and > external parties to ensure that our course of action is appropriate and > commensurate with our business practices and accommodates our

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

I see both sides on this matter. On the one hand, certlint/cablint catches lots of obvious problems, mostly with ridiculous certificate profiles or manual special purpose issuances. Certainly, there's a lot of bad issuance that having it in the blocking path might help with... but... If one

Re: TrustCor root inclusion request

Andrew. Thank you for the review, comments and questions on TrustCor's policy documents. We are in the process of reviewing your comments and formulating a response to each. We will provide our response and updates before EOB Tuesday, August 15th, published to this discussion list. Have a

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

On Thursday, August 10, 2017 at 11:51:54 PM UTC-4, Eric Mill wrote: > 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

Re: dNSName containing '/' / low serial number entropy

On 11/08/2017 15:39, Policy Authority PKIoverheid wrote: 2. Why did DDY not implement the serial number entropy as required by the Baseline Requirements? 3. Was this detected by the auditor? If not, why not? ANSWER ON QUESTION 2: DDY concluded wrongly that ballot 164 was not applicable for

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 1:22 PM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote: > > Could you expand on this? It's not obvious what you mean. > > I guess I was unclear. My concern was that one

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Friday, 11 August 2017 16:49:29 UTC+1, Ryan Sleevi wrote: > Could you expand on this? It's not obvious what you mean. I guess I was unclear. My concern was that one obvious way to approach this is to set things up so that after the certificate is signed, Boulder runs cablint, and if it

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 11:48:50AM -0400, Ryan Sleevi via dev-security-policy wrote: > On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote: > > > Given that these

Re: dNSName containing '/' / low serial number entropy

On top of what Ryan has written, I want to specifically praise the approach of actually checking a sample of certificates as PKIoverheid describes. I think done well this can be a very affordable yet timely and effective way to detect problems in a particular issuance pipeline or with a

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Fri, Aug 11, 2017 at 11:40 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote: > > Given that these were all caught by cablint, has Let's Encrypt considered > > integrating it into your issuance

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

On Friday, 11 August 2017 14:19:57 UTC+1, Alex Gaynor wrote: > Given that these were all caught by cablint, has Let's Encrypt considered > integrating it into your issuance pipeline, or automatically monitoring > crt.sh (which runs cablint) for these issues so they don't need to be > caught

Re: Certificates with less than 64 bits of entropy

On 8/11/2017 7:26 AM, Ben Wilson wrote: > > With regard to Siemens, given the large number of certificates and > the disruption that massive revocations will have on their > infrastructure, what does this community expect them to do? > Each violation of published requirements for the operation

Re: dNSName containing '/' / low serial number entropy

Mark, Thanks for providing a detailed report about this, including the steps being taken to prevent future events like this. Your proposed remediation plans sound like excellent steps to ensure future conformance, and demonstrate an understanding as to the root causes and how to prevent them in

RE: Certificates with less than 64 bits of entropy

QuoVadis Enterprise Trust CA 2 G3 signed the Siemens Issuing CA Internet Server 2016. From: Jeremy Rowley Sent: Friday, August 11, 2017 8:36 AM To: Ben Wilson Cc: Alex Gaynor ; Jonathan Rudenberg ;

Re: dNSName containing '/' / low serial number entropy

Dear Mozilla Security Policy Community, My apologies for the delayed follow up response. As stated in my email from 07/25/2017, Digidentity (DDY), one of our TSP’s, issued 777 certificates from September 30th 2016 which were not compliant with BR ballot 164. DDY has fixed the problem with the

Re: Certificates with less than 64 bits of entropy

They are no longer issuing from the digicert cross. The issue is within their PKI but there should be no additional certificates chained to DigiCert roots On Aug 11, 2017, at 8:33 AM, Ben Wilson > wrote: Apparently they haven’t yet, but

RE: Certificates with less than 64 bits of entropy

Apparently they haven’t yet, but we’ll assume that they will. Does the community expect a remediation plan for their code and then a revocation-and-replacement plan? Ben Wilson, JD, CISA, CISSP VP Compliance +1 801 701 9678 From: Alex Gaynor [mailto:agay...@mozilla.com] Sent:

Re: Certificates with less than 64 bits of entropy

Have they fixed whatever issue there is with their PKI infrastructure that leads to this issue? From skimming, I see this pool contains certs issued as recently as one month ago. Alex On Fri, Aug 11, 2017 at 10:26 AM, Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org>

RE: Certificates with less than 64 bits of entropy

With regard to Siemens, given the large number of certificates and the disruption that massive revocations will have on their infrastructure, what does this community expect them to do? -Original Message- From: dev-security-policy

Re: Certificates with invalidly long serial numbers

Given the rarity of such events, it will be hard for subscribers to ensure they properly handle automated "renew prematurely" messages, so other contact methods designed to reach human operators would often be preferable. But for fully automated "fire-and-forget" servers, I think the most

Re: Certificates with improperly normalized IDNs

On Thu, Aug 10, 2017 at 1: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 to

Re: 2017.08.10 Let's Encrypt Unicode Normalization Compliance Incident

Hi Josh, Given that these were all caught by cablint, has Let's Encrypt considered integrating it into your issuance pipeline, or automatically monitoring crt.sh (which runs cablint) for these issues so they don't need to be caught manually by researchers? Alex On Thu, Aug 10, 2017 at 11:00 PM,

Re: Certificates with invalidly long serial numbers

This is a great point, re:automated issuance systems like ACME. I've suggested to the Let's Encrypt folks the idea of a "should I re-issue" endpoint that clients can poll. This would give CAs a programatic ability to broadcast to subscribers that they should reissue now because the cert is about