RE: DigiCert-Symantec Announcement

roots once the systems requiring a specific Symantec roots are deprecated or as path validation errors arise. Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, September 14, 2017 1:28 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-securi

DigiCert mis-issuance report: rekeyed certificates

Hi all, On Friday, Sep 15, we discovered that 1090 certificates were rekeyed using expired domain validation documents. In each case, the original certificate's domain was properly verified at time of issuance using an approved method. Organization verification properly completed for each

RE: DigiCert-Symantec Announcement

, 2017 1:28 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:

RE: CAA Certificate Problem Report

Well, we are checking CAA and DNSSEC per our implementation. Looks great on our side and against our tests. Some individuals disagree though. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, September 11, 2017 3:42 PM To: Jeremy Rowley <jeremy.row...@digicert.com>; Jo

RE: CAA Certificate Problem Report

I would support that. I can't recall why it's in there. -Original Message- From: Jonathan Rudenberg [mailto:jonat...@titanous.com] Sent: Monday, September 11, 2017 3:19 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: R

RE: CAA Certificate Problem Report

the experience for that particular set of customers is easier. That bucket can then be improved later. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent

RE: CAA Certificate Problem Report

: Re: CAA Certificate Problem Report On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote: > That's the entire corpus of information related to DNSSEC in the BRs. Under 4 > and 5, we successfully returned a DNS record. The lookup didn’t fail so the > sentence "the doma

RE: CAA Certificate Problem Report

-- From: Andrew Ayer [mailto:a...@andrewayer.name] Sent: Saturday, September 9, 2017 1:01 PM To: Jonathan Rudenberg <jonat...@titanous.com> Cc: Jonathan Rudenberg via dev-security-policy <dev-security-policy@lists.mozilla.org>; Peter Bowen <pzbo...@gmail.com>; mozilla-dev-security-pol.

Re: CAs not compliant with CAA CP/CPS requirement

Let me pull the data and share it with you. For some reason we saw a few sub domains right before the 8th. We added *.digicerts.com at the last minute until we had time to figure out why. I suspect it's being caused by documentation or a partner telling the customers the wrong thing. Once we

Re: CAs not compliant with CAA CP/CPS requirement

I would have checked Sept 9th as Sept 8th at midnight would be the last possible moment when the CPS could be updated and still be compliant. > On Sep 9, 2017, at 3:33 PM, Andrew Ayer via dev-security-policy > wrote: > > On Fri, 8 Sep 2017 15:22:52 -0700

CAA Certificate Problem Report

Hi everyone, We received a certificate problem report at 11 pm on Sep 8, 2017 from Andrew Ayer alleging the mis-issuance of 6 certificates because of a failure to properly verify CAA records. I'm sharing the report here because there are questions about CAA record checking that we feel

RE: CAs not compliant with CAA CP/CPS requirement

Hi Andrew, I'm not certain how to update the previous Mozilla response with respect to CAA, but we added the following as authorized CAA records: Digicert.com *.digicert Digicert.net.jp Cybertrust.net.jp I wasn't sure if adding a wildcard to the CAA record is kosher, but I didn't seem anything

Re: CAs not compliant with CAA CP/CPS requirement

Hey Andrew, we are checking CAA records at time of issuance. The CPS update should publish today. > On Sep 8, 2017, at 1:25 PM, Andrew Ayer via dev-security-policy > wrote: > > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's

RE: DigiCert-Symantec Announcement

eciate your thoughts. Jeremy From: Peter Kurrasch [mailto:fhw...@gmail.com] Sent: Thursday, August 3, 2017 11:21 PM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: DigiCert-Symantec Announ

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

C 5280 https://tools.ietf.org/html/rfc5280#section-4.2.1.12) stating that anyEKU places no restrictions on the subject key as to its purpose. Is that correct? On Fri, Aug 18, 2017 at 9:53 AM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:d

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

of this policy to conform to the Baseline Requirements. Is SSL certificate defined? On Aug 18, 2017, at 7:33 AM, Gervase Markham <g...@mozilla.org<mailto:g...@mozilla.org>> wrote: On 17/08/17 20:31, Jeremy Rowley wrote: Without an FQDN, I doubt they are in scope for the baseline

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

Without an FQDN, I doubt they are in scope for the baseline requirements. They are in scope for the Mozilla policy. The BRs require the cert to be intended for web tls. These are not. The Mozilla policy covers client certs as well as tls. > On Aug 17, 2017, at 12:27 PM, identrust--- via

RE: SRVNames in name constraints

Ah. Sorry about that. I agree that no CA can issue those yet. -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Tuesday, August 15, 2017 9:04 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Gervase Markham <g...@mozilla.org>; Ryan Sleevi <

RE: SRVNames in name constraints

I realize use of underscore characters was been debated and explained at the CAB Forum, but I think it's pretty evident (based on the certs issued and responses to Ballot 202) that not all CAs believe certs for SRVNames are prohibited. I realize the rationale against underscores is that 5280

RE: Symantec Update on SubCA Proposal

Hi Jakob, Your below description raises two questions of general interest (though not of interest to the Mozilla root program): 1. Will DigiCert establish cross-signatures from the old/historic Symantec roots to continuing DigiCert roots and subCAs? [JR] We won’t be cross-signing from

RE: Certificates with reserved IP addresses

Hey Ryan, Here's the report from CTJ: Number of affected certificates: One. After receiving the revocation request from DigiCert, CTJ scanned their certificate database for additional certificates. This is the only active certificate with a reserved IP. CTJ issued the

RE: Symantec Update on SubCA Proposal

Hi wizard, Although DigiCert will acquire the assets related to Symantec’s CA business, DigiCert is not required to use those assets in its business operations. We are organizing the operations of DigiCert to meet the requirements established in the Managed CA proposal. This includes having

RE: Certificates with reserved IP addresses

The CTJ one was issued in 2013 and is a five year cert (which was also prohibited under the BRs at that time_. It should have been revoked much earlier, of course. -Original Message- From: dev-security-policy

Re: Certificates with less than 64 bits of entropy

: Ben Wilson <ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>> Cc: Jeremy Rowley <jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>; Jonathan Rudenberg <jonat...@titanous.com<mailto:jonat...@titanous.com>>; mozilla-dev-security-pol...@l

RE: Certificates with invalidly long serial numbers

reviously suggested 14 days for live certificates that don't > cause actual security issues. This would be enough for most > subscribers to either get a reissued certificate (for free) from the > original CA or set up an account with a competing CA and get at least a basic > OV ce

RE: Certificates with metadata-only subject fields

but that revocation was not necessary in this case. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Thursday, August 10, 2017 12:24 PM To: mozilla-dev-security-pol

RE: Certificates with invalidly long serial numbers

to either get a reissued certificate (for free) from the original CA or set up an account with a competing CA and get at least a basic OV cert. On 10/08/2017 03:02, Jeremy Rowley wrote: > No objection to 72 hours v. 1 business day. I agree it should be > short and > 72 hours seems

RE: Certificates with metadata-only subject fields

, 2017 12:24 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: 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

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

metadata. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, August 10, 2017 12:24 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with metadata-only subject fields Can you provide an example of wh

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

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: 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 invalidly long serial numbers

-policy Sent: Wednesday, August 9, 2017 4:57 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: > All CAS are required to maintain the capability to process and rece

RE: Certificates with metadata-only subject fields

And this is exactly why we need separate tiers of revocation. Here, there is zero risk to the end user. I do think it should be fixed and remediated, but revoking all these certs within 24 hours seems unnecessarily harsh. I think there was a post about this a while ago, but I haven't been

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

Of Gervase Markham via dev-security-policy Sent: Wednesday, August 9, 2017 9:34 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: High traffic on this list, and Mozilla root program involvement On 09/08/17 00:12, Jeremy Rowley wrote: > Do you want that added as a new bug for

Re: Certificates with invalidly long serial numbers

and the rightful owner of a domain wanted the cert revoked. Alex On Wed, Aug 9, 2017 at 10:19 AM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: All CAS are required to maintain the capability

Re: Certificates with invalidly long serial numbers

rg> wrote: > >> On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote: >> 24 hours is super short when it's a Saturday morning at 4 am and it’s a >> European government entity. I agree that is what the policy says now, but, >> for lower risk item

RE: Certificates with invalidly long serial numbers

24 hours is super short when it's a Saturday morning at 4 am and it’s a European government entity. I agree that is what the policy says now, but, for lower risk items, the policy should change, preferably to at least one business day. -Original Message- From: dev-security-policy

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

Do you want that added as a new bug for all the issues listed? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Gervase Markham via dev-security-policy Sent: Tuesday, August 8, 2017 10:02 AM To:

Re: CA Problem Reporting Mechanisms

+1. CAs should be required to support certificate problem reports sent through a specified email address. It simplifies the process a lot if CAs use at least one common mechanism. > On Aug 8, 2017, at 12:22 PM, Jonathan Rudenberg via dev-security-policy >

RE: DigiCert-Symantec Announcement

Hey Peter, I think the Mozilla and Google plans both stand as-is, although probably need an updated based on this announcement. I'm hoping that the high-level concepts remain unchanged: - Migrate to a new infrastructure - Audit the migration and performance to ensure

RE: DigiCert-Symantec Announcement

, Peter Bowen wrote: > On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Today, DigiCert and Symantec announced that DigiCert is acquiring > > the Symantec CA assets, including the infrastructur

RE: DigiCert-Symantec Announcement

to:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Jeremy Rowley via dev-security-policy > Sent: Wednesday, August 2, 2017 10:54 PM > To: Peter Kurrasch <fhw...@gmail.com>; mozilla-dev-security-policy > <mozilla-dev-security-pol...@li

Re: DigiCert-Symantec Announcement

I believe all of the non expired CAs listed are in scope. > On Aug 2, 2017, at 7:44 PM, Peter Bowen <pzbo...@gmail.com> wrote: > > On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> Today, D

RE: DigiCert-Symantec Announcement

* Will there be other players in Symantec's SubCA plan or is DigiCert the only one? [DC] Only DigiCert. * ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase

RE: DigiCert-Symantec Announcement

Hey Nick - I plan to include all relevant OIDs in the cert. I figured that way relying parties understand the total risk associated with verification of the certificate, even if they don't know exactly the methods tied to each listed domain. If a method is eventually deemed less desirable (*cough*

RE: DigiCert-Symantec Announcement

+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson via dev-security-policy Sent: Wednesday, August 2, 2017 4:07 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley

DigiCert-Symantec Announcement

Hi everyone, Today, DigiCert and Symantec announced that DigiCert is acquiring the Symantec CA assets, including the infrastructure, personnel, roots, and platforms. At the same time, DigiCert signed a Sub CA agreement wherein we will validate and issue all Symantec certs as of Dec 1, 2017.

RE: Miss-issuance: URI in dNSName SAN

Each CA is required (under the BRs) to provide public information on how to submit certificate problem reports, including mis-issued certificates. The only way to properly notify the CA is through that mechanism as those are monitored 24 hours. CAs participating on the list usually have a couple

RE: Certificate with invalid dnsName

Thank you, Charles and Tom, for bringing this to the forefront. We have contacted the cross-signed partner and asked for an explanation. We've also demanded revocation within 24 hours and a full scan to determine whether any other certificates exist. Jeremy -Original Message- From:

Re: Certificate with invalid dnsName issued from Baltimore intermediate

You should also filter out expired certs as they aren't usable. > On Jul 19, 2017, at 8:30 AM, Alex Gaynor via dev-security-policy > wrote: > > I think there might be a bug in your SQL, one of the offending certs is > issued by "C=US, O=U.S. Government,

RE: Certificate with invalid dnsName issued from Baltimore intermediate

Some of these certs are really old. Is there a reason people were using double dot names? Are they all mistakes in the certificate request or is there some logic behind them? -Original Message- From: dev-security-policy

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

Thanks Rob. Appreciate the links. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Tuesday, July 4, 2017 3:50 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert policy violation

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

zilla.org Subject: Re: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886 On Tuesday, 4 July 2017 02:37:36 UTC+1, Jeremy Rowley wrote: > [JR] Well yeah - but this one is self-signed and self-issued, so how > does it chain? This seems to be a source of confusion for

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

Thanks Nick. I'm missing something on this, so I appreciate the help so far. I replied to each section. Perhaps you have confused transitivity with commutativity or one of the other simple properties. Transitivity is the property whereby if F(A,B) and F(B,C) then F(A,C), for example the "greater

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

ert policy violation - non-disclosure of https://crt.sh/?id=160110886 On Monday, 3 July 2017 22:00:00 UTC+1, Jeremy Rowley wrote: > Link please to a formal definition? As your email alleges a policy violation by one a cross-signed CAs, we take the investigation and response very seriously. I'd

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

-compliance. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Monday, July 3, 2017 2:14 PM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert policy violation - non-disclosure of https://crt.

RE: SRVNames in name constraints

Isn't this ballot ready to go? If we start the review period now, it'll be passed by the time the Mozilla policy is updated. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Peter Bowen via

RE: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

I am surprised you decided to fork the thread from here https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM where this was already being discussed. Seems unnecessary. I don't agree this is a policy violation, and I doubt any CA not involved in the previously

Re: When are public applications embedding certificates pointing to 127.0.0.1 OK?

And a common practice. Old Microsoft documentation used to recommend it. > On Jun 21, 2017, at 12:22 PM, Santhan Raj via dev-security-policy > wrote: > > On Wednesday, June 21, 2017 at 12:02:51 PM UTC-7, Jonathan Rudenberg wrote: >>> On Jun 21, 2017, at

RE: New undisclosed intermediates

If you added them automatically to OneCRL, how would you create new intermediates? Would it be anything over X days old and undisclosed is automatically added? If so, +1 from us. I'm pretty sure the two CAs listed from the Baltimore root don't believe these are publicly trusted intermediates.

RE: StartCom issuing bogus certificates

Agreed - the license to use the domain granted by IANA is only for inclusion in documents (https://www.iana.org/domains/reserved). There isn't a license to use the domain for testing or any other purposes. -Original Message- From: dev-security-policy

RE: CA Validation quality is failing

Okay - all certs were added to the CT log. We're now working through revocation. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Tuesday, May 2, 2017

RE: CA Validation quality is failing

Okay – we’ll add them all to CT over the next couple of days. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Tuesday, May 2, 2017 9:08 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: r...@sleevi.com; Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists

RE: CA Validation quality is failing

Thanks! The revocation timeline changes are coming today/tomorrow morning. -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Tuesday, May 2, 2017 4:55 AM To: r...@sleevi.com; Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozil

RE: CA Validation quality is failing

certs 82 entities are affected if we revoke just the 150 certs What else would you like to know? Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, May 1, 2017 5:01 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Gervase Markham <g...@mozilla.org>;

RE: CA Validation quality is failing

Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, April 27, 2017 2:41 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Validation quality is failing On 27/04/17 00:16, Jeremy Rowley wro

RE: Symantec Conclusions and Next Steps

Thanks Alex. Greatly appreciated. From: Alex Gaynor [mailto:agay...@mozilla.com] Sent: Thursday, April 27, 2017 2:05 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Rob Stradling <rob.stradl...@comodo.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@li

RE: Symantec Conclusions and Next Steps

Your post made me realize that we never publicly posted the status of these last few CAs. Sorry about that. Here's the plan: 1. ABB - ABB was supposed to be technically constrained (and is restricted to certain names). However, the technical constraints were added incorrectly and didn't exclude

RE: CA Validation quality is failing

isleading; Thoughts? Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Thursday, April 20, 2017 6:11 PM To: mozilla-dev-security-policy <m

RE: CA Validation quality is failing

FYI - still looking into this. I should have a report tomorrow. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Wednesday, April 19, 2017 2:27 PM

RE: CA Validation quality is failing

That was changed in ballot 127. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kurt Roeckx via dev-security-policy Sent: Wednesday, April 19, 2017 5:54 PM To: Peter Gutmann

RE: CA Validation quality is failing

I’m looking into it right now. I’ll report back shortly. Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, April 19, 2017 2:25 PM To: Mike vd Ent <pasarellaph...@gmail.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; J

RE: Certificate issues

-policy Sent: Tuesday, April 18, 2017 10:59 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificate issues On 18/04/17 17:22, Ryan Sleevi wrote: > On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via > dev-security-policy < dev-security-policy@lists.mozilla.org> wr

RE: Certificate issues

They are not currently logged to CT (because they were supposed to be code signing certificates). We can add them to our log though. Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Tuesday, April 18, 2017 10:22 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozil

Certificate issues

Hi everyone, On Friday at 1:00 pm, we accidently introduced a bug into our issuance system that resulted in five serverAuth-code signing certificates that did not comply with the Baseline Requirements. The change modified a handful of code signing certificates into a pseudo- SSL profile.

RE: Symantec Response B

Because the certificate improperly included Symantec's BR-compliance OID. If the cert wasn't a BR-covered certificate but included the BR compliance OID, then the cert was still mis-issued and should be disclosed. Jeremy -Original Message- From: dev-security-policy

RE: Symantec Response B

I am curious about the software requiring the 1024 bit cert off the root. The dates of mis-issuance are 2013-2014, which is still early in adoption of the BRs. At that time, the scope of the BRs was confusing and lead to lots of discussions. Although the term "intended to be used for

RE: DRAFT - BR Self Assessments

Hi Kathleen, This is a good idea, and I like the phased-in approach. The mapping exercise is similar to how other communities evaluate inclusion requests and makes it more apparent how the CA is complying with the various Mozilla requirements. An extension on this could be to have CAs annually

RE: Next CA Communication

-policy Sent: Monday, March 20, 2017 2:29 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Next CA Communication On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote: > On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via > > [JR] This should be limited to SSL

RE: Mozilla Root Store Policy 2.4.1

Given that the patent disclosures have been withdrawn, the proposed changes in ballot 190, and that the validation working group will be working on a revised ballot for the remaining methods during the face to face, could Action 1 include methods added/revised in ballots adopted after 1.4.1? That

RE: Symantec: Next Steps

We have DTP and RA roles slated as part of the validation WG discussion, but only as they relate to validation. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi via dev-security-policy

RE: DigiCert BR violation

Sent: Monday, March 13, 2017 3:32 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert BR violation On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote: > I don't disagree that teletext shouldn't be used, and we no longer > include it in new certi

RE: DigiCert BR violation

Although we have a policy against using live certificates for testing, the policy was not followed in this case. Can you share why? Can you share what steps you'll be taking to make sure policies are followed in the future? I think we've seen some pretty stark examples about what can happen

RE: Symantec: Next Steps

Cut: > An unwatched RA and a sub-CA are effectively equivalent in power. A > watched RA and a sub-CA might not be, if the CA is exercising > effective control and limits on their issuance. There is a distinction > in the BRs between an RA and a sub-CA, with the RA having less onerous >

RE: DigiCert BR violation

Thanks. This certificate was issued by an employee of DigiCert as a test on our systems to see if we'd resolved an issue with a path permitting CN fields greater than 64 characters. Obviously, the issue wasn't resolved and the JIRA is still open. We're deploying a patch shortly to fix path and

Re: Maximum validity of pre-BR certificates

icy > <dev-security-policy@lists.mozilla.org> wrote: > > On Sat, Mar 4, 2017 at 12:22 PM, Daniel Cater via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: >> On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley wrote: >>> 1.0 is not the d

RE: Maximum validity of pre-BR certificates

@lists.mozilla.org] On Behalf Of Daniel Cater via dev-security-policy Sent: Saturday, March 4, 2017 1:22 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Maximum validity of pre-BR certificates On Saturday, 4 March 2017 20:14:09 UTC, Jeremy Rowley wrote: > 1.0 is not the definitive vers

RE: Maximum validity of pre-BR certificates

1.0 is not the definitive version any more. As of 2015‐04‐01, Section 6.3.2 prohibits validity periods longer than 39 months. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Daniel Cater via

RE: (Possible) DigiCert EV Violation

I was just going to respond with something similar. Appendix F: "A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension

Re: Misissued/Suspicious Symantec Certificates

Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> wrote: On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley <jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>> wrote: Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting re

Re: Misissued/Suspicious Symantec Certificates

Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results. Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point. > On Feb 22, 2017, at 8:33 PM, Ryan

RE: Other Curves

Works for me. Any idea on when Mozilla is planning to permit Curve22519 and Curve448? I’d like to plan for that date. From: Richard Barnes [mailto:rbar...@mozilla.com] Sent: Wednesday, February 1, 2017 4:04 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Hanno Böck <ha...@hboe

RE: Other Curves

I think I should mention that I suggested secp256k1 for blockchain reasons... -Original Message- From: Hanno Böck [mailto:ha...@hboeck.de] Sent: Wednesday, February 1, 2017 3:52 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: r...@sleevi.com; mozilla-dev-securi

RE: Other Curves

...@hboeck.de] Sent: Wednesday, February 1, 2017 3:52 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Other Curves On Wed, 1 Feb 2017 22:38:54 + Jeremy Rowley <jeremy.row...@digicert.com> wr

RE: Other Curves

That’s a pretty vague argument against adding some curves. With that logic, we’d never have moved away from MD5 hash as moving away would have disrupted the ecosystem… From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, February 1, 2017 3:46 PM To: Jeremy Rowley <jeremy.

RE: Other Curves

in RFCs, HSMs, and in applications. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, February 1, 2017 3:34 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Other Curves That seems altogether a bad idea for the eco

RE: Other Curves

Both preferably, but I’d accept at the EE level. Primarily secp256k1 and brainpool, but mostly secp256k1. From: Richard Barnes [mailto:rbar...@mozilla.com] Sent: Wednesday, February 1, 2017 3:35 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-securi

Other Curves

I know the use of other ECC curves comes up often, but I couldn't recall where Mozilla landed on using other ECC curves. Requests for secp256k1 and brainpool curves are increasing rapidly. If Mozilla updated its policy, we could start using these curves for client certs, even if the baseline

<    1   2   3   4   >