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
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
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
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
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
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
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
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
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
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
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.
-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
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
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
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
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
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
>
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
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
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
>
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
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
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*
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.
* 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
, 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
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
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
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
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 ;
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
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
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
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
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
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
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
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
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
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
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
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>]
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
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
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
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
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
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:
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,
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
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
"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
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
>&
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.
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
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
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
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
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
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
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:
+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
>
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
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
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
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
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,
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
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
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
..@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>
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
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
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
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.
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
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
, 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:
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 - 100 of 293 matches
Mail list logo