RE: Certificates with less than 64 bits of entropy

2017-08-18 Thread Stephen Davidson via dev-security-policy
Thanks Ryan, and I note your further posting regarding prompt response.  Noting your desire for detail, I have hesitated to respond with partial answers as both Siemens and QuoVadis are working hard to fix the issues with the Siemens CA and to replace the certificates as quickly as possible.

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread identrust--- via dev-security-policy
On Wednesday, August 16, 2017 at 1:45:12 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 16, 2017, at 12:52, Jonathan Rudenberg via dev-security-policy > > wrote: > > > > I looked through the CT logs and found 15 more unexpired unrevoked > > certificates

RE: Responding to a misissuance

2017-08-18 Thread Doug Beattie via dev-security-policy
> -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Friday, August 18, 2017 9:42 AM > To: Doug Beattie ; richmoor...@gmail.com; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Responding to a misissuance > > On

TBSCertificate / Certificate Linting APIs

2017-08-18 Thread Rob Stradling via dev-security-policy
In response to the many BR compliance issues [1] that have been reported here this month, there's been renewed interest in certificate linting. Various CAs have said that they're considering plugging one or more certificate linters into their certificate issuance processes. Some CAs, such as

Misissuance response status update

2017-08-18 Thread Jonathan Rudenberg via dev-security-policy
For those who aren’t following Bugzilla closely, here’s a quick update on where things are with the large batch of misissuance bugs that was filed this week. Most CAs have provided an initial response, and many have finished their initial incident reviews and provided details. Only two CAs

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread identrust--- via dev-security-policy
On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote: > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy > > wrote: > > > > Hello, In reference to 3)"Certificates that appear to be intended as client > >

The State of CRLs Today

2017-08-18 Thread J.C. Jones via dev-security-policy
All, As part of some related research, I did some analysis of availability, size, and download latency of the CRLs currently known in Censys. There are a number of CRLs missing, or whose DNS no longer resolves; a number of graphs of size and latency, and the code.

WISeKey mis-issued EV certificates with wrong validity (Post-Morten)

2017-08-18 Thread pfuentes--- via dev-security-policy
Dear all, I'm Pedro Fuentes, from WISeKey this is to raise an issue communicated to us by Alex Gaynor, about some test EV certificates that we issued with wrong validity period. We identified the issue as a human error while defining the initial template for the tests issued for our test domain

Re: Bugzilla Bugs re CA issuance of non-compliant certs

2017-08-18 Thread Kathleen Wilson via dev-security-policy
On Friday, August 18, 2017 at 6:35:23 AM UTC-7, Gervase Markham wrote: > On 17/08/17 00:18, Kathleen Wilson wrote: > > == Let’s Encrypt == > > RESOLVED (no bug needed) > > > == Staat der Nederlandend / PKIoverheid == > > RESOLVED (no bug needed) > > While the timely responses and performance of

Re: Certificates with less than 64 bits of entropy

2017-08-18 Thread Matt Palmer via dev-security-policy
On Fri, Aug 18, 2017 at 04:04:48PM +, Stephen Davidson via dev-security-policy wrote: > Siemens has previously indicated that the affected certificates are > installed on high profile websites and infrastructure for Siemen’s group > companies around the world, and that a rushed revocation

Re: Certificates with less than 64 bits of entropy

2017-08-18 Thread Ryan Sleevi via dev-security-policy
On Fri, Aug 18, 2017 at 1:34 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Since QuoVadis has not yet responded, let me point to a few (partial) > answers already known from previous messages from QuoVadis or others: I believe it would be far more

Responding to a misissuance

2017-08-18 Thread Gervase Markham via dev-security-policy
I've started a wiki page giving Mozilla expectations and best practices for CAs responding to a misissuance report. (No idea why I decided to write that now...) https://wiki.mozilla.org/CA/Responding_To_A_Misissuance Comments on whether the content is correct, and what might be missing, are most

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Ryan Sleevi via dev-security-policy
Do you believe https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope is ambiguous in this context? That is what is referenced in the text. It sounds as if you're suggesting they're in scope, via 1.1, but that they're out of scope, because the policy does not state that

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Jeremy Rowley via dev-security-policy
I don't (as these are the exact type of cert I've been trying to kill for years), but Identrust did based on their response. Looking at it from their POV, the language could probably be clarified to state thar any cert with no equipment, sever Auth, or anyEKU is considered a BR cert regardless

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Ryan Sleevi via dev-security-policy
Doesn't RFC 5280 clearly indicate that already, through its normative description of the EKU? That is, I can understand there being confusion or misinterpretation, but I'm not sure that the problem itself is rooted in the documents, and thus, may not be something the documents need to address. :)

BR compliance of legacy certs at root inclusion time

2017-08-18 Thread Gervase Markham via dev-security-policy
Sometimes, CAs apply for inclusion with new, clean roots. Other times, CAs apply to include roots which already have a history of issuance. The previous certs issued by that CA aren't always all BR-compliant. Which is in one sense understandable, because up to this point the CA has not been bound

Re: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

2017-08-18 Thread Jonathan Rudenberg via dev-security-policy
+mdsp > On Aug 18, 2017, at 05:56, ramirommu...@gmail.com wrote: > > Hi Jonathan > You are right, we are going to look into this, taken into account that the > same serial number should be in the real certificate. > > Regards > > El jueves, 17 de agosto de 2017, 19:54:31 (UTC+2), Jonathan

Re: Certificate with invalid dnsName issued from Baltimore intermediate

2017-08-18 Thread Gervase Markham via dev-security-policy
On 15/08/17 16:53, Ben Wilson wrote: > Attached is an audit from 2016. They are due for another one for 2017. Attachments don't appear on this list, but I have the docs. Please email me if you'd like them. I've asked Ben to update CCADB to point to them, and to also update any other entries

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Gervase Markham via dev-security-policy
On 17/08/17 20:31, Jeremy Rowley wrote: > Without an FQDN, I doubt they are in scope for the baseline requirements. Not according to the BRs themselves. However, the Mozilla Policy 2.5 specifically says: "Insofar as the Baseline Requirements attempt to define their own scope, the scope of this

Re: Bugzilla Bugs re CA issuance of non-compliant certs

2017-08-18 Thread Gervase Markham via dev-security-policy
On 17/08/17 00:18, Kathleen Wilson wrote: > == Let’s Encrypt == > RESOLVED (no bug needed) > == Staat der Nederlandend / PKIoverheid == > RESOLVED (no bug needed) While the timely responses and performance of these CAs is commendable, it may be worth opening a bug and recording the events and

Re: Responding to a misissuance

2017-08-18 Thread Gervase Markham via dev-security-policy
Hi Rich, On 18/08/17 12:51, richmoor...@gmail.com wrote: > Perhaps some explicit statements about sub-CAs would be helpful - > detailing where responsibility lies and how a CA is required to deal > with a sub-CA who is found to have misissued. Do you specifically mean sub-CAs which are run by

Re: O=U.S. Government for non-USG entity (IdenTrust)

2017-08-18 Thread Jeremy Rowley via dev-security-policy
Right, but can you call these SSL certs without an FQDN? * Insofar as the Baseline Requirements attempt to define their own scope, the scope of this policy (section 1.1) overrides that. Mozilla thus requires CA operations relating to issuance of all SSL certificates in the scope of this

Re: AC FNMT Usuarios and anyExtendedKeyUsage

2017-08-18 Thread Eric Mill via dev-security-policy
Hi Jose, There was no attachment to your email. Would you mind re-sending with an attachment? On Fri, Aug 18, 2017 at 8:17 AM, Jose Manuel Torres via dev-security-policy wrote: > Hello everyone, > > In response to the questions raised: > > AC FNMT

Re: AC FNMT Usuarios and anyExtendedKeyUsage

2017-08-18 Thread Eric Mill via dev-security-policy
Hi Jose, Apologies, on looking back through m.d.s.p, it's clear attachments aren't processed by the list configuration. Would you be able to post it to a URL, or attach it to a bugzilla bug? -- Eric On Fri, Aug 18, 2017 at 10:01 AM, Eric Mill wrote: > Hi Jose, > > There was

Re: Responding to a misissuance

2017-08-18 Thread Gervase Markham via dev-security-policy
On 18/08/17 13:03, Doug Beattie wrote: > And if there is any guidance on processing misissuance reports for > Name constrained sub-CA vs. not name constrained, that would be > helpful also. What parts of a response do you think might be different for name-constrained sub-CAs? Gerv

Re: AC FNMT Usuarios and anyExtendedKeyUsage

2017-08-18 Thread Kurt Roeckx via dev-security-policy
On 2017-08-18 16:01, Eric Mill wrote: Hi Jose, There was no attachment to your email. Would you mind re-sending with an attachment? Attachments never make it to the list. Kurt ___ dev-security-policy mailing list

Re: Responding to a misissuance

2017-08-18 Thread richmoore44--- via dev-security-policy
Perhaps some explicit statements about sub-CAs would be helpful - detailing where responsibility lies and how a CA is required to deal with a sub-CA who is found to have misissued. ___ dev-security-policy mailing list

Re: AC FNMT Usuarios and anyExtendedKeyUsage

2017-08-18 Thread Jose Manuel Torres via dev-security-policy
Hello everyone, In response to the questions raised: AC FNMT Usuarios do not issue TLS / SSL certificates, as evidenced by the attached document: Audit Attestation - ETSI Assestment 2017, FNMT CA's and TSU's. Regarding anyExtendedKeyUsage EKU, since January 2017 it is no longer incorporated

RE: Responding to a misissuance

2017-08-18 Thread Doug Beattie via dev-security-policy
And if there is any guidance on processing misissuance reports for Name constrained sub-CA vs. not name constrained, that would be helpful also. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On

Re: BR compliance of legacy certs at root inclusion time

2017-08-18 Thread Ryan Sleevi via dev-security-policy
On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Sometimes, CAs apply for inclusion with new, clean roots. Other times, > CAs apply to include roots which already have a history of issuance. The > previous certs issued by

Re: BR compliance of legacy certs at root inclusion time

2017-08-18 Thread Kristian Fiskerstrand via dev-security-policy
[Intro; long time lurker but I rarely post, but given this is an open question not directly tied to any CA or official capacity my opinions are..] On 08/18/2017 05:02 PM, Gervase Markham via dev-security-policy wrote: > Sometimes, CAs apply for inclusion with new, clean roots. Other times, > CAs

BR compliance of legacy certs at root inclusion time

2017-08-18 Thread Nick Lamb via dev-security-policy
I'll speak up for transparency again. In terms of policy the most vital thing is that a CA tells us about such certs during application. One way to do that would be to CT log them, but especially for small sets there might be other sensible ways. If we can't be shown the certs in question (or