Re: Certificates with less than 64 bits of entropy

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: Bugzilla Bugs re CA issuance of non-compliant certs

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: O=U.S. Government for non-USG entity (IdenTrust)

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 > >

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

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

The State of CRLs Today

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.

Misissuance response status update

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)

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

> -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

RE: Certificates with less than 64 bits of entropy

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.

TBSCertificate / Certificate Linting APIs

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

BR compliance of legacy certs at root inclusion time

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

Re: BR compliance of legacy certs at root inclusion time

[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

Re: BR compliance of legacy certs at root inclusion time

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

BR compliance of legacy certs at root inclusion time

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: O=U.S. Government for non-USG entity (IdenTrust)

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. :)

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

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)

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: AC FNMT Usuarios and anyExtendedKeyUsage

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: AC FNMT Usuarios and anyExtendedKeyUsage

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: AC FNMT Usuarios and anyExtendedKeyUsage

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: O=U.S. Government for non-USG entity (IdenTrust)

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: Responding to a misissuance

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: Responding to a misissuance

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: Bugzilla Bugs re CA issuance of non-compliant certs

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: O=U.S. Government for non-USG entity (IdenTrust)

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: Certificate with invalid dnsName issued from Baltimore intermediate

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: Mensaje privado sobre: Miss-issuance: URI in dNSName SAN

+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: AC FNMT Usuarios and anyExtendedKeyUsage

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

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: Responding to a misissuance

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

Responding to a misissuance

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: Certificates with less than 64 bits of entropy

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