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: Misissued/Suspicious Symantec Certificates

I am aware of the requirements but am interested in seeing how an RA that doesn't have their own issuing cert structures the audit report. It probably looks the same, but I've never seen one (unless that is the case with the previously provided audit report). On Feb 22, 2017, at 8:48 PM, Ryan

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: 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: 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: Next CA Communication

I only understand this "independent validation of domain control" because I'm on the thread. I don't think CAs who aren't actively involved will understand what it means. DigiCert has an RA. It's DigiCert. We validate our certificate orders and submit them to the CA for issuance. I think it

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: 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: 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 Cc: mozilla-dev-security-policy ; Jeremy Rowley

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

la-dev-security-pol...@lists.mozilla.org Subject: Re: Certificate issues On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Hi everyone, On Friday at 1:00 pm, we acc

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

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

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: DigiCert BR violation

No - there are no clients that need Teletext that I'm aware of. ETA on the other issues are the CN field is already fixed to limit the size to 64 characters. For the others, we wanted to talk to the primary customer to let them first know the fix is going live. Should be deployed later this

RE: Maximum validity of pre-BR certificates

Yes - several CAs issued 60 month+ certs prior to 1.0. In fact, 10 year certs were not especially uncommon. The validity period available depended largely on the CA. -Original Message- From: dev-security-policy

Re: Maximum validity of pre-BR certificates

Common practice amongst certain cas. There were several cas that have always opposed cert validity periods longer than three years. This opposition lead to the reducing the validity period first to 60 months then to 39 months. > On Mar 4, 2017, at 2:01 PM, Peter Bowen via dev-security-policy >

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: DigiCert-Symantec Announcement

Thanks Kathleen. We already offer short-lived certs (anywhere from 8 hours up), but they are not issued off a dedicated intermediate. It's a great suggestion, and we'll add it to the DigiCert plan. Jeremy -Original Message- From: dev-security-policy

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*

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

, 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

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

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

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: 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 Cc: Gervase Markham ; 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: 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 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 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: 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 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 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

ed into issuance pipelines. Discussions at this point are extremely relevant, as they speak to how well the CA is staying abreast of changes, as well as how effectively they're managing their subsidiaries - both issues that are key to public trust. On Thu, Aug 10, 2017 at 2:17 PM, Jerem

RE: Certificates with metadata-only subject fields

hey speak to how well the CA is staying abreast of changes, as well as how effectively they're managing their subsidiaries - both issues that are key to public trust. On Thu, Aug 10, 2017 at 2:17 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mail

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

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

tions will have on their infrastructure, what does this community expect them to do? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben<mailto:dev-security-policy-bounces%2Bben>=digicert@lists.mozilla.org<mailto:digicert....@lists.mozilla.org>]

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: 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 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: 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: 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: DigiCert policy violation - non-disclosure of https://crt.sh/?id=160110886

sh/?id=160110886 On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote: > 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. Hi Jerem

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

"Previously accepted without comment" is hardly accurate. There's lots of comments on the Mozilla policy (including Ben's comment on this very term). And it's hardly fair to deride my lack of understanding on what transitive trust entails in the digital certificate space considering it's outside

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

icy violation - non-disclosure of > https://crt.sh/?id=160110886 > > On 03/07/17 16:10, Jeremy Rowley via dev-security-policy wrote: >> I am surprised you decided to fork the thread from here >> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/sNDN6q26_uM >&

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

I'm an idiot. The discussion wasn't meant to be a red herring. Just a momentary lapse in intelligence... It really looks like this from a validation perspective, right? EE -> Self-signed -> Issuing CA (as it has the same key) -> Digicert Root Yeah - I agree it should have been disclosed.

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: 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: 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: 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: Symantec Conclusions and Next Steps

sts.mozilla.org> Subject: Re: Symantec Conclusions and Next Steps On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Your post made me realize that we never publicly p

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: High traffic on this list, and Mozilla root program involvement

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 bug per issue on one bug per CA. For example, should there be

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

No objection to 72 hours v. 1 business day. I agree it should be short and 72 hours seems perfectly reasonable . -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Paul Kehrer via

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

All CAS are required to maintain the capability to process and receive revocation requests 24x7 under the baseline requirements. The headache is not with the CA. Rather, it's notifying the customer that their certificate will be revoked before the start of the next business day. Having a one to

RE: DigiCert-Symantec Announcement

Hi everyone, We’re still progressing towards close and transition. One of the items we are heavily evaluating is the root structure and cross-signings post close. Although the plan is still being finalized, I wanted to provide a community update on the current proposal. Right now,

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)

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: 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 ; mozilla-dev-security-pol...@lists.mozilla.org

RE: CA Validation quality is failing

..@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: CA Validation quality is failing On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org>

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: 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: 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: 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: CA Validation quality is failing

There isn't anything in our CPS directly. However, we state that we follow the baseline requirements in the CPS. The baseline requirements give a profile for the state field. We weren't sure this was strictly followed. We finished our validation review over the weekend. There are about 3000

RE: CA Validation quality is failing

mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Validation quality is failing On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: There isn't anything in o

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:

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

ty-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:dev-security-policy@lists.mozilla.org> > wrote: Hi everyone, Today, DigiCert and Symantec annou

RE: DigiCert-Symantec Announcement

ty-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > > The current end-state plan for root cross-signing is provided at > https://bugzilla.mozill

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

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

RE: CAA Certificate Problem Report

Not saying we implemented DNSSEC checking correctly, but I don't think the requirements are as clear as you present them. The BRs state that: " CAs are permitted to treat a record lookup failure as permission to issue if: • the failure is outside the CA's infrastructure; • the

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: CAA Certificate Problem Report

ailing to do the right thing makes it OK to do the wrong thing are the worst arguments to make :) On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: I would support that.

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

e: CAA Certificate Problem Report > On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > For a little more context, the idea is that we can speed up the CAA check for > all customers while working with those w

RE: CAA Certificate Problem Report

I think that's the opposite of what I'm saying. CAs don't need to do DNSSEC provided 1) they don't want to issue certs where DNSSEC is implemented and 2) the CAA record check times out, and 3) there is a way to check if DNSSEC is present without doing the entire chain validation. #3 is what

RE: DigiCert-Symantec Announcement

Is this a correct summary? There’s four categories of customers that require trust in existing Symantec roots being address: 1. Those that can migrate to a new trusted root because they use the certs in a standard TLS-configuration 2. Those that require a certain Symantec root

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: Anomalous Certificate Issuances based on historic CAA records

il.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Anomalous Certificate Issuances based on historic CAA records This whole conversation makes me wonder if CAA Transparency should be a thing. On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <dev-securi

RE: Anomalous Certificate Issuances based on historic CAA records

I think we can be more transparent about CAA records without requiring CT. I don’t have a solution, but more transparency about processing CAA records couldn’t hurt. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, November 30, 2017 3:12 PM To: Tim Hollebeek

RE: Anomalous Certificate Issuances based on historic CAA records

The Thawte records aren't showing any CAA record preventing wildcards either. Here's the Thawte CAA record logs for the domain: 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500

DigiCert/Symantec updates

Hey everyone, I wanted to give the community and update on how the DigiCert-Symantec transition is going and make everyone aware of a few issues I recently created on Bugzilla. First, the good news. DigiCert has started validating and issuing certificates through the Symantec platform

RE: Incident Report : GoDaddy certificates with ROCA Fingerprint

Hey Alex - we intend to publish a report for the former Symantec certs. For now, here's what I know: 1) The scope was 15 TLS certs. We became aware of the certs through your posting. 2) We are revoking all 15 certs. I'm still waiting for their serial numbers. We kicked off the 24 hour

  1   2   3   >