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
> requirem
I don't disagree that teletext shouldn't be used, and we no longer include
it in new certificate requests or renewals. However, we do include teletext
in certificates that originally had teletext strings but are being re-keyed.
Teletext inclusion wasn't intentional and should shortly be fixed.
-
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
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
week,
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
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
w
A) Does your CA have an RA program, whereby non-Affiliates of your company
perform aspects of certificate validation on your behalf under contract? If
so, please tell us about the program, including:
* How many companies are involved
* Which of those companies do their own domain ownership valid
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
should
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 fi
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 authenticating
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
[mailto:dev-security-p
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. Becau
Subject: Re: Certificate issues
On Tue, Apr 18, 2017 at 12:09 PM, Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
Hi everyone,
On Friday at 1:00 pm, we accidently introduced a bug into our issuance
system that resulted in five serverAut
v-security-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.
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
; Ben Wilson
Subject: Re: CA Validation quality is failing
On We
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
Cc: Ryan Sleevi ;
mozi
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
To
. 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
To: r...@sleevi.com; Mike vd Ent
inaccurate or misleading;
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
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 I
Thanks Alex. Greatly appreciated.
From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Thursday, April 27, 2017 2:05 PM
To: Jeremy Rowley
Cc: Rob Stradling ; mozilla-dev-security-policy
Subject: Re: Symantec Conclusions and Next Steps
On Thu, Apr 27, 2017 at 3:52 PM, Jeremy Rowley via
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
Validation quality is failing
On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
There isn't anything in our CPS directly. However, we state that we follow the
baseline requirements in the CPS. T
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
Subject: Re: CA Validation q
eremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: Gervase Markham mailto:g...@mozilla.org> >;
mozilla-dev-security-pol...@lists.mozilla.org
<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: CA Validation quality is failing
On Mon, May 1, 2017 at
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,
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
[mailto:dev-security-policy-bounces+je
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.
--
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 14:41, urijah--- via dev-security-policy
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 mention
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 dev-sec
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 Jeremy. That thread discusses a
"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 of
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
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. Apologi
ce.
>
> -Original Message-
> From: Rob Stradling [mailto:rob.stradl...@comodo.com]
> Sent: Monday, July 3, 2017 2:14 PM
> To: Jeremy Rowley ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: DigiCert policy violation - non-disclosure of
> https://crt.
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
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lis
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, OU=Department of Homeland Security,
> OU=
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: de
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 of
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.
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
[mailto:dev-security-policy-bounces+je
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*
* 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 cer
I believe all of the non expired CAs listed are in scope.
> On Aug 2, 2017, at 7:44 PM, Peter Bowen wrote:
>
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
> wrote:
>> Today, DigiCert and Symantec announced that DigiCert is acquiring the
>
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 ; mozilla-dev-security-policy
>
> Subject: RE: DigiCert-Symantec Announcement
> *
2017 at 6:44:51 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
> wrote:
> > Today, DigiCert and Symantec announced that DigiCert is acquiring
> > the Symantec CA assets, including the infrastructure, personnel,
> > roots,
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 complianc
+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
> wrote:
>
>
>> On Aug 8, 2017, at 10:
I agree that the 24 hours seems excessive for some of these. Ive proposed at
the cab forum we bifuracte the revocation periods to key compromise vs non key
compromise. I'd love support there on the proposal. However, I think that until
the rules change formally, CAs should be required to meet th
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: m
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
[mai
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
he 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
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
All CAS are required to maintain the capability to process and receive
revocation requests 24x7 under the
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
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 able
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 dev-security-polic
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
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@l
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 Da
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
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, Jere
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
pre-
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
mailto:dev-security-policy@lists.mozilla.org> >
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
autom
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
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 Of
unces+ben<mailto:dev-security-policy-bounces%2Bben>=digicert@lists.mozilla.org<mailto:digicert....@lists.mozilla.org>]
On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Thursday, August 10, 2017 12:01 PM
To: Jonathan Rudenberg mailto:jonat...@titanous.com>>;
mozilla-de
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
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.
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 al
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 g2-sanfull01.ctjssl.in
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 Digi
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
requir
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 ; Peter
Bowen ; mozilla-dev-security-policy
Subject: Re: SRVNames i
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 dev-sec
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
po
RFC 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
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
Ri
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, Moz
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 Certificate
> Policy and/or Certificatio
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 p
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 are
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 (PDT)
> Andy Warner via dev-security-po
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 tra
Thanks Gerv - we're working on a patch today for it. We'll also revoke the
cert today.
-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Monday, September 11, 2017 9:12 AM
To: Jeremy Rowley ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificat
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 loo
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 I'm
improving 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-p
lem Report
> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy
> wrote:
>
> For a little more context, the idea is that we can speed up the CAA check for
> all customers while working with those who have DNSSEC to make sure they
> aren't killing performance
wrong thing are the worst arguments to make :)
On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
I would support that. I can't recall why it's in there.
-Original Message-
From: Jonathan Rudenber
, 2017 1:28 PM
To: Jeremy Rowley
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
mailto:dev-security-policy@lists.mozilla.org> > wrote:
Hi everyone,
Today, DigiCe
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
rek
: DigiCert-Symantec Announcement
On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org> > wrote:
Hi everyone,
Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastr
Post-close, all products and offerings will stay the same as pre-close
except that DigiCert will do the validation and issuance. This does mean
DigiCert is offering a DV product post close. We agreed with Ryan that
separation by root for DV, OV, and EV doesn't make much sense, meaning all
TSL cer
bject: Re: DigiCert-Symantec Announcement
On Tue, Sep 19, 2017 at 8:39 PM, Jeremy Rowley via dev-security-policy
wrote:
>
> The current end-state plan for root cross-signing is provided at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1401384. The diagrams there show
> all of the
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 for
The current plan is to create a new root that is cross-signed by each of the
four roots we've identified as critical for customers
(https://bugzilla.mozilla.org/show_bug.cgi?id=1401384). If Mozilla
whitelisted this sub CA, the same as Google's and Apple's, the entire issue
around rapid root inclusi
Assuming the rule applies only to externally run third parties, I think it's
an excellent idea, but perhaps it should be a public pre-notification? As
you mentioned, the relationship will become transparent through CCDAB
submission and the audit report, so what's the advantage of keeping it
private
Some initial thoughts
1. I'm a bit confused by bullet #2 in the survey. Wasn't it already the
Mozilla policy that CAs could only use the blessed 10 methods of validation?
I thought this was communicated in the previous letter?
2. On bullet #3, I'm reading the wording to mean either 1) disclosed a
I'm also very interested in this scenario.
I'm also interested in what happens if a trusted DigiCert root is signed by
a Symantec root. I assume this wouldn't impact trust since the chain
building would stop at a DigiCert root, but I wanted to be sure.
-Original Message-
From: dev-secur
Yes. Or any root that is cross signed by the Symantec sub cas. I assume there
would be zero impact as the chain building should stop with the trustees root
and not look at the Symantec roots, but it’s definitely good to double check.
On Oct 27, 2017, at 10:32 AM, Peter Bowen
mailto:pzbo...@gmai
Thanks Gerv and Kathleen. We really appreciate you posting this, and I find the
Mozilla guidance extremely helpful. Here's where we are at with the current
migration plan:
1) As of Dec. 1, DigiCert will validate and issue all certificates requested
through Symantec. Symantec's front end syste
201 - 300 of 314 matches
Mail list logo
