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
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
, 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:
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
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
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
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
--
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.
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
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
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
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
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
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
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
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
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 <
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
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
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 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
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
: 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
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
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
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
, 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
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
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
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
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
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
-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
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
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
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
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
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
>
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
, 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
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
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
* 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
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*
+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
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.
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,
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
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
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
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
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
-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.
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
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
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
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.
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
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
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
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
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>;
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
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
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
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
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
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
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
-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
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
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.
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 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
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
-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
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
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
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
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
>
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
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
@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
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
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
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
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
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
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
...@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
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.
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
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
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
201 - 300 of 392 matches
Mail list logo