RE: Updating CA:SubordinateCA_checklist

2013-10-17 Thread Jeremy Rowley
On this page, a sub CA could refer to the organization holding an intermediate certificate or an intermediate certificate. If the latter, then I think you need to retain third-party to distinguish between intermediates covered by the CAs own audit and those covered under a separate audit.

RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences?

2013-10-28 Thread Jeremy Rowley
+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Jeremy Rowley Sent: Monday, October 28, 2013 1:29 PM To: 'Brian Smith'; 'Rick Andrews' Cc: dev-security-policy@lists.mozilla.org Subject: RE: Netcraft blog, violations of CABF Baseline Requirements, any consequences? There are lots of occasions: 1

RE: Grace Periods for Subordinate CA Certificates

2013-11-01 Thread Jeremy Rowley
Hi Kathleen, Can you clarify whether this applies only to third-party Sub CA certificates or internal subordinate CAs? A lot of the inclusion policy seems applicable only to external sub CAs. If the certificate is covered by our WebTrust audit, is operated solely by DigiCert, and is only used

RE: Mozilla not compliant with RFC 5280

2013-11-08 Thread Jeremy Rowley
: Friday, November 8, 2013 11:51 AM To: Jeremy Rowley Cc: fhw...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I don't believe there are any parties who you would want as CAs that support the idea of getting rid of revocation checking

RE: Exceptions to 1024-bit cert revocation requirement

2013-12-11 Thread Jeremy Rowley
If you are granting more time, I have a whole bunch of customers who are not happy about the 2013 cutoff. Extending it for some CAs is patently unfair to those of us who have taken a hard stance on the deadline and not requested extensions of time. If you are granting some CAs an extension,

RE: Exceptions to 1024-bit cert revocation requirement

2013-12-11 Thread Jeremy Rowley
with a qualification because of non-revoked 1024 bit certs. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Jeremy Rowley Sent: Wednesday, December 11, 2013 6:01 PM To: 'Rob Stradling'; 'Kathleen Wilson'; mozilla

RE: DigiCert Request to Include Renewed Roots

2014-01-29 Thread Jeremy Rowley
As outlined in the root inclusion request, we need to embed all five for fully support our community. Here's why: 1) These root certificates are used in many different systems, not just Mozilla. If Mozilla doesn't embed all of them, the ones not embedded will essentially be untrusted. The

RE: DigiCert Request to Include Renewed Roots

2014-01-29 Thread Jeremy Rowley
support, they permitted us to include five roots. Jeremy -Original Message- From: Eddy Nigg [mailto:eddy_n...@startcom.org] Sent: Wednesday, January 29, 2014 2:34 PM To: Jeremy Rowley; mozilla-dev-security-pol...@lists.mozilla.org Cc: 'Gervase Markham'; 'Brian Smith'; mozilla-dev-security

RE: DRAFT: May CA Communication

2014-05-12 Thread Jeremy Rowley
Kathleen, Can you explain #5 a bit? I apologize if this was previously answered, but does this rule apply to all intermediates used by the CA itself or only those existing outside of the CA's PKI? Seems like ones operated solely by Te CA(and covered by the CA's audit) don't necessarily require

RE: DRAFT: May CA Communication

2014-05-12 Thread Jeremy Rowley
Of Kathleen Wilson Sent: Monday, May 12, 2014 4:46 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DRAFT: May CA Communication On 5/12/14, 2:24 PM, Jeremy Rowley wrote: Kathleen, Can you explain #5 a bit? I apologize if this was previously answered, but does this rule apply

RE: DRAFT: May CA Communication

2014-05-12 Thread Jeremy Rowley
Wilson Sent: Monday, May 12, 2014 5:39 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DRAFT: May CA Communication On 5/12/14, 4:07 PM, Jeremy Rowley wrote: Won't this policy encourage bad naming practices in intermediate certificates? If a CA creates an intermediate

RE: DRAFT: May CA Communication

2014-05-13 Thread Jeremy Rowley
=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Tuesday, May 13, 2014 8:20 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DRAFT: May CA Communication On 5/13/14, 6:07 AM, Gervase Markham wrote: On 13/05/14 01:44, Jeremy Rowley wrote: Also, the technical constraint

RE: DRAFT: May CA Communication

2014-05-13 Thread Jeremy Rowley
-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Tuesday, May 13, 2014 9:38 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DRAFT: May CA Communication On 5/13/14, 8:32 AM, Jeremy Rowley wrote: Sorry - I mixed points

RE: CA Communication - May 12, 2014

2014-05-14 Thread Jeremy Rowley
To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA Communication - May 12, 2014 On Monday, 12 May 2014 13:45:16 UTC-6, Jeremy Rowley wrote: +1. This is especially true in the federal space where some intermediates are stored offline most of the time. Per Section 4.9.7 of the FBCA CP

RE: Question about disclosing subCA certs

2014-05-14 Thread Jeremy Rowley
She's clarified in the discussion thread that it is all SubCAs chained to the a CAs root certificate that must be disclosed, regardless of who controls the private key. Jeremy -Original Message- From: dev-security-policy

RE: Checking certificate requirements

2014-05-20 Thread Jeremy Rowley
Cool. It's good to see that the number of certs with these issues has declined significantly, especially considering the valid from date. Have you emailed the CAs issuing these certs to let them know they might have issuance issues? -Original Message- From: dev-security-policy

RE: Checking certificate requirements

2014-05-20 Thread Jeremy Rowley
I saw that he's contacting CAs about the missing SANs, but what about the other issues? I'd be very interested in hearing about any non-compliant certs related to DigiCert (if there are any). Jeremy -Original Message- From: dev-security-policy

RE: Checking certificate requirements

2014-05-20 Thread Jeremy Rowley
Please do! -Original Message- From: Kurt Roeckx [mailto:k...@roeckx.be] Sent: Tuesday, May 20, 2014 2:22 PM To: Jeremy Rowley Cc: 'Kathleen Wilson'; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Checking certificate requirements On Tue, May 20, 2014 at 12:31:14PM -0600

RE: Only accepting 2048 bit or better certificates

2014-06-21 Thread Jeremy Rowley
I think getting them revoked would be the first step. If you make the data available about which CAs still have 1024 bit certs or lower, we could email the CAs and find out what is going on. Jeremy -Original Message- From: dev-security-policy

RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

2014-07-23 Thread Jeremy Rowley
Right - all adding the OIDs does is specify in the certificate which BR section was used to perform the validation. There isn't a security indicator attached. Jeremy -Original Message- From: dev-security-policy

Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

2014-07-23 Thread Jeremy Rowley
Ryan Hurst wrote a blog post on this very topic not too long ago. His conclusion was that determining, programmatically, the difference was difficult. See http://unmitigatedrisk.com/?p=203. This is mostly because there are some certs that still include a domain in the org field. Requiring a

RE: GlobalSign Request to Include ECC Roots

2014-07-30 Thread Jeremy Rowley
I do not think specifying a version number is required. All CAs issuing EV certs (or SSL) are required to abide by the latest version of the guidelines and attest to that fact in their CPS using the prescribed CAB Forum language: [Name of CA] conforms to the current version of the CA/Browser

RE: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

2014-07-30 Thread Jeremy Rowley
is an assertion of compliance with the latest version of the guidelines, meaning versioning is largely irrelevant. Jeremy -Original Message- From: Ryan Sleevi [mailto:ryan-mozdevsecpol...@sleevi.com] Sent: Sunday, July 27, 2014 9:11 PM To: Jeremy Rowley Cc: 'ryan-mozdevsecpol...@sleevi.com

RE: New wiki page on certificate revocation plans

2014-07-31 Thread Jeremy Rowley
This is great. Thanks Richard! For OneCRL and the EE certs, establishing parameters around when an EE is eligible for inclusion would give guidance to CAs about when to report revocations. Is the OneCRL intended for when the cert is compromised because of a breach of the CA? Or can high

RE: New wiki page on certificate revocation plans

2014-08-01 Thread Jeremy Rowley
Some information on performance is available here: http://ocspreport.x509labs.com/. You might be able to reach out to them and get the actual data related to number of failed responses. Whether fails and speed are major issues depends on who you ask. Jeremy -Original Message-

RE: New wiki page on certificate revocation plans

2014-08-03 Thread Jeremy Rowley
Why does OneCRL seem like a hack? Considering how infrequently intermediates and roots are revoked, OneCRL seems like a satisfactory way to provide this information long-term, provided that the certs are removed from OneCRL at some point. I'd think they could safely remove the OneCRL certs

RE: New wiki page on certificate revocation plans

2014-08-04 Thread Jeremy Rowley
Seems like a lot of anecdotes are being shared with respect to hard fail without a lot of data. Do the browsers have more data on this? Considering the X.509 labs shows nearly 100% availability with response times of about 100 ms, data showing in-depth info on failure rates (and the reasons

RE: New wiki page on certificate revocation plans

2014-08-04 Thread Jeremy Rowley
, 2014 10:35 AM To: Jeremy Rowley Cc: Matthias Hunstock; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans Firefox 31 data: on desktop the median successful OCSP validation took 261ms, and the 95th percentile (looking at just the universe

RE: New wiki page on certificate revocation plans

2014-08-05 Thread Jeremy Rowley
I think most CAs use CDNs to help serve OCSP responses quite fast and reliably. A breakdown of failure rates based on certificate provider could provide insight on what's going on. Is gathering this information too close to violating a user's privacy for Mozilla? Any chance of peering into

RE: Wildcard cert, no intermediate

2014-08-20 Thread Jeremy Rowley
The cert is allowable as long as the root is 1024, not the end entity. The end entity must be 2048 under the current Mozilla requirements. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf

Code Signing Draft

2014-08-25 Thread Jeremy Rowley
The CAB Forum released a proposed new baseline requirements around code signing today that might be of interest to participants here. You can see the document here: https://cabforum.org/2014/08/25/cabrowser-forum-releases-code-signing-baseline-requirements-public-comment-draft/ Public

RE: Code Signing Draft

2014-08-29 Thread Jeremy Rowley
sets of keys. Jeremy -Original Message- From: fhw...@gmail.com [mailto:fhw...@gmail.com] Sent: Friday, August 29, 2014 7:39 AM To: Jeremy Rowley; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Code Signing Draft Thanks for sharing this Jeremy. I'm still reading through

RE: Code Signing Draft

2014-08-29 Thread Jeremy Rowley
...@sleevi.com] Sent: Friday, August 29, 2014 12:44 PM To: Jeremy Rowley Cc: 'fhw...@gmail.com'; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Code Signing Draft On Fri, August 29, 2014 8:04 am, Jeremy Rowley wrote: Good point. I don't think we spell it out, but I don't think anyone

RE: Short-lived certs

2014-09-04 Thread Jeremy Rowley
They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the

RE: Short-lived certs

2014-09-04 Thread Jeremy Rowley
Yeah - the cert would have to be shorter than the longest acceptable OCSP response for certificates. I think that's set to 10 days in the CAB Forum, but I'd be surprised if anyone issues OCSP responses that are valid that long. The issue of revocation checking is where the proposal died in the

RE: Short-lived certs

2014-09-04 Thread Jeremy Rowley
site visitors sufficient notice that something is going wrong. Jeremy -Original Message- From: fhw...@gmail.com [mailto:fhw...@gmail.com] Sent: Thursday, September 4, 2014 12:33 PM To: Jeremy Rowley; 'David E. Ross'; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived

RE: Short-lived certs

2014-09-17 Thread Jeremy Rowley
I agree that we should reduce the validity period of OCSP responses and also that must staple is a high priority. 10 day responses is way too long (although I doubt any CAs are actually doing 10 days). Mozilla appears to be considering their entire revocation policy at this time, including

Re: Short-lived certs

2014-09-22 Thread Jeremy . Rowley
I wouldn't be worried about a browser rejecting a cert that doesn't comply. Instead, I'd be worried about a qualified audit showing non-compliance. Although Mozilla might not care about that particular non-compliance, other browsers and partners might. Jeremy On 9/22/2014 8:36 AM, Gervase

Re: KIR S.A. Root Inclusion Request

2014-09-25 Thread Jeremy . Rowley
If you look under Section 13.2.4, a CA cannot remove an entry from its CRLs, meaning there is no way to un-suspend a certificate. On 9/25/2014 7:03 AM, Certificates wrote: Answers for Jeremy Rowley questions: A couple of notes: 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL

Re: Client certs

2014-09-25 Thread Jeremy . Rowley
Also, policy and authorization is often embedded in client certs. Software that knows how to read this information can provide permissions based on the included policy. This is used by first responders and large distributed networks where the credential acts as their permission to participate

RE: KIR S.A. Root Inclusion Request

2014-09-26 Thread Jeremy Rowley
@lists.mozilla.org] On Behalf Of Przemyslaw Rawa Sent: Friday, September 26, 2014 7:31 AM To: dev-security-policy@lists.mozilla.org Subject: KIR S.A. Root Inclusion Request Answer for suspension and OCSP issues (Robin Alden and Jeremy Rowley): RFC 5280 allows suspension. In our opinion, suspension is a usefull

RE: KIR S.A. Root Inclusion Request

2014-09-26 Thread Jeremy Rowley
I think you should clarify what constitutes a document confirming rights to the domain. Is this authorization from the registrar or registrant? Who provides the document? -Original Message- From: dev-security-policy

RE: Organization info in certs not being properly recognized by Firefox

2014-10-27 Thread Jeremy Rowley
As you know, the CAB Forum guidelines do not mandate use of CAB Forum policy OIDs to assert DV/OV compliance. We'd happily support a change in this policy at the CAB Forum and plan to update our certs accordingly if such ballot passes. Jeremy -Original Message- From:

RE: dev-security-policy Digest, Vol 70, Issue 24

2014-10-29 Thread Jeremy Rowley
Comodo offers 3 levels: DV - PositiveSSL OV - InstantSSL EV - EV SSL DigiCert (as well as the EU CAs as you mentioned) only offers two levels - OV and EV. Jeremy -Original Message- From: dev-security-policy

Re: dev-security-policy Digest, Vol 70, Issue 24

2014-10-29 Thread Jeremy . Rowley
Correct - we (DigiCert) reserved the OID but don't issue certs under it. Jeremy On 10/29/2014 3:41 PM, John Nagle wrote: On 10/29/2014 01:40 PM, Jeremy Rowley wrote: Comodo offers 3 levels: DV - PositiveSSL OV - InstantSSL EV - EV SSL Comodo's CPS is at https://www.comodo.com/repository

Re: Clarification about WebTrust BR and WebTrust EV audits

2014-11-06 Thread Jeremy . Rowley
This list is missing a security audit. I'd recommend the a network security audit (or something else) that provides some assurance of network security. Since the BRs are explicitly referenced by the EV Guidelines (and incorporated therein), why not require a BR audit plus EV for an EV

RE: Updating Peers of Mozilla's CA Certificates and CA Certificate Policy modules

2015-02-06 Thread Jeremy Rowley
I dislike the idea. Other CAs contribute to the discussion but should not the gatekeeper. Ryan Sleevi makes complete sense since Google uses the NSS store. Commercial CAs actually having a say on another CA's inclusion (outside of the current public discussion) seems like something that

RE: Updating Peers of Mozilla's CA Certificates and CA Certificate Policy modules

2015-02-05 Thread Jeremy Rowley
Just one thought - Richard Barnes involvement with Let's Encrypt makes it look like Mozilla is promoting its own CA over the others. If there's any question on Let's Encrypt getting favoritism, Mozilla will be opening itself up to an anti-trust lawsuit, especially in Europe where vertical

RE: Question about BR Commitment to Comply

2015-01-28 Thread Jeremy Rowley
Some initial thoughts: 1) Membership in the CAB Forum is not required for a CA to commit to complying with the BR, and if non-membership avoids any obligation to comply with the BRs, I think you'll quickly see a mass exodus from the group. No member of the CAB Forum is bound to its

RE: Question about BR Commitment to Comply

2015-01-30 Thread Jeremy Rowley
Snipped to try and make the convo less confusing. [MH] If that's the case, the trustworthiness of a Webtrust audit would be weakened. Auditors should obtain the CA's assertion of compliance, and assess whether it's reasonable with respect to the CA's CP/CPS and the target scope of audit (i.e.

RE: Certificate Profiles

2015-03-16 Thread Jeremy Rowley
Not to mention, that the lack of a required OCSP URI (with a stapled response) is something that the forum has talked about correcting a few times. It's likely going to be required (hopefully with an exception for short lived certs). Jeremy -Original Message- From: dev-security-policy

RE: Question about BR Commitment to Comply

2015-01-29 Thread Jeremy Rowley
Some initial thoughts: 1) Membership in the CAB Forum is not required for a CA to commit to complying with the BR, and if non-membership avoids any obligation to comply with the BRs, I think you'll quickly see a mass exodus from the group. No member of the CAB Forum is bound to its

RE: Question about BR Commitment to Comply

2015-01-29 Thread Jeremy Rowley
Kurt said I think that the webtrust audit is also based on a certain version of the BR and that they might not have been updated yet to check the latest version. So I think the audit report should indicate which version was checked. If an audit was not for the last version that doesn't mean

RE: Consequences of mis-issuance under CNNIC

2015-03-23 Thread Jeremy Rowley
Although CT would not have prevented issuance, requiring CT for all certificates would have detected the misissuance much sooner. Maybe Mozilla should be the first to require CT for all certificates? Jeremy -Original Message- From: dev-security-policy

RE: Are CAs required to update their CPS annually

2015-04-06 Thread Jeremy Rowley
And to make sure they at least looked at it. If nothing changed, then you can simply update the date and republish. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Kurt Roeckx Sent: Monday,

Re: Are CAs required to update their CPS annually

2015-04-04 Thread Jeremy Rowley
We update ours annually. A new one is about to be posted. Eugene imfasterthanneutr...@gmail.com wrote: According to the CA Baseline Requirements section 8.2.1, The CA SHALL develop, implement, enforce, and **annually update** a Certificate Policy and/or Certification Practice Statement that

Re: Are CAs required to update their CPS annually

2015-04-04 Thread Jeremy Rowley
Should have read your email more carefully. Yes all cas are required to update annually. Those that don't are out of compliance. I think its even one of the criteria under webtrust. Eugene imfasterthanneutr...@gmail.com wrote: According to the CA Baseline Requirements section 8.2.1, The CA

RE: [FORGED] Name issues in public certificates

2015-11-17 Thread Jeremy Rowley
While interesting, this report is probably going to be used for a lot of misleading statements. There's lots to consider in this: 1) Considering that the 3-year validity cap was a recent requirement, I'm surprised your search only resulted in 50,000 certificates with all of the 5-10 year

RE: [FORGED] Name issues in public certificates

2015-11-17 Thread Jeremy Rowley
Encoding an IP Address in a dNSName is not permitted by the BRs. This is what Peter's "_ipv4_not_allowed_here" rule refers to, IIUC. [JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers to work back then? Chrome and IE did not process ipAddress properly. Jeremy >

RE: Mozilla Policy - Suggestion for the future

2015-08-26 Thread Jeremy Rowley
I agree with Steve. Being able to compare CP documents readily is the point behind the 3647 format. We converted the BRs to 3647 so members can compare their CPS side-by-side with the BRs and see where there is a deficiency. Comparing the Mozilla policy in a 3647 would make the CPS reviews and

RE: [FORGED] Name issues in public certificates

2015-11-17 Thread Jeremy Rowley
...@comodo.com] Sent: Tuesday, November 17, 2015 2:12 PM To: Jeremy Rowley Cc: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org; Peter Bowen; Peter Gutmann Subject: Re: [FORGED] Name issues in public certificates On 17/11/15 18:27, Jeremy Rowley wrote: > Encoding an IP Address in a dNSN

RE: Intermediate certificate disclosure deadline in 2 weeks

2016-06-21 Thread Jeremy Rowley
* snip - since only OneCRL is relevant to Mozilla users with respect to intermediate certs* >> OneCRL is intended to reduce the exposure of Mozilla's browser to the second >> category of problems, by burning a CRL for intermediates into the software >> itself, so that it will function even

Re: Intermediate certificate disclosure deadline in 2 weeks

2016-06-21 Thread Jeremy Rowley
Agreed. I don't see a reason to disclose anything where the parent is revoked. I think it's a similar question as whether a CA has to disclose all the sub case under a root where removal from the root program was requested. In both cases the certs are not publicly trusted and don't affect the

RE: Intermediate certificate disclosure deadline in 2 weeks

2016-06-22 Thread Jeremy Rowley
That's why Mozilla has a policy to disclose all such CAs through OneCRL. Seems like unnecessary information to disclose the CA as part of OneCRL and as part of the Salesforce program. -Original Message- From: dev-security-policy

RE: Intermediate certificate disclosure deadline in 2 weeks

2016-06-23 Thread Jeremy Rowley
...@konklone.com] Sent: Thursday, June 23, 2016 2:41 PM To: Ben Wilson <ben.wil...@digicert.com> Cc: Peter Bowen <pzbo...@gmail.com>; Kurt Roeckx <k...@roeckx.be>; Richard Barnes <rbar...@mozilla.com>; Jeremy Rowley <jeremy.row...@digicert.com>; Steve <steve.me...@gma

RE: More SHA-1 certs

2016-02-03 Thread Jeremy Rowley
: Wednesday, February 3, 2016 9:05 PM To: Jeremy Rowley Cc: Rick Andrews; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: More SHA-1 certs Are CAs really not monitoring issuance of certs by their sub-CAs for simple violations like this? Does this not violate a Mozilla or CAB Forum policy

RE: Proposed limited exception to SHA-1 issuance

2016-02-24 Thread Jeremy Rowley
I think Rob's questions are great and should be answered before deciding. Many CAs have roots and can issue certs that browsers will simply reject. There may be a simple way to provide them certs without issuing a ton of SHA1s that are placed on OneCRL. -Original Message- From:

RE: Proposed limited exception to SHA-1 issuance

2016-02-24 Thread Jeremy Rowley
...@mozilla.org] Sent: Wednesday, February 24, 2016 9:11 AM To: Jeremy Rowley; Rob Stradling; mozilla-dev-security-pol...@lists.mozilla.org Cc: Kathleen Wilson; Richard Barnes Subject: Re: Proposed limited exception to SHA-1 issuance On 24/02/16 15:45, Jeremy Rowley wrote: > I think Rob's questi

RE: Proposed limited exception to SHA-1 issuance

2016-02-24 Thread Jeremy Rowley
Technically, Worldpay had a lot longer than four days to figure this out It's not like SHA1 issues jumped out from a behind a bush to scare everyone. I believe the concern is that Worldpay is asking for an exception by saying, "We've tried 'things' and they didn't work - can we please have a

RE: SHA1 certs issued this year chaining to included roots

2016-01-19 Thread Jeremy Rowley
Thanks we are investigating. This was a SubCA that existed well before our acquisition of the Baltimore roots. We are contracting the customer and are requesting a full report. Jeremy -Original Message- From: dev-security-policy

RE: New requirement: certlint testing

2016-02-10 Thread Jeremy Rowley
I don't think we should have to use a competitor's product to evaluate this. Are we permitted to set up our own instance of this using the open source to do the testing? There should be that option considering IP rights have not been freely granted on all this software. -Original

RE: SHA-1 S/MIME certificates

2016-03-30 Thread Jeremy Rowley
I think a required move away from SHA1 client certs requires a bit more planning. 1) There hasn't been a formal deprecation of all SHA-1 certificates in any root store policy. There has been a formal deprecation by the CAB Forum of SHA1 server certificates. Considering many of the client cert

RE: Drafting Q1 2016 CA Communication

2016-03-23 Thread Jeremy Rowley
What about code signing and s/MIME certs? Code signing is still used by MS for legacy software until Jan 2017. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of kwil...@mozilla.com Sent: Tuesday,

RE: Drafting Q1 2016 CA Communication

2016-03-23 Thread Jeremy Rowley
10:26 AM, Jeremy Rowley wrote: > What about code signing and s/MIME certs? Code signing is still used > by MS for legacy software until Jan 2017. > > On Tuesday, March 22, 2016 at 9:33:19 AM UTC-7, kwi...@mozilla.com wrote: >> The following 'ACTION #1c' has been added to the co

RE: More SHA-1 certs

2016-03-03 Thread Jeremy Rowley
ing, I don't agree that Symantec violated any rule the Forum has set. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Thursday, March 3, 2016 2:49 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org; sanjay_m...@symantec.com Subject:

RE: Fixing the BR scope (was Re: More SHA-1 certs)

2016-03-07 Thread Jeremy Rowley
Programmatic enforcement is outside the scope of the BRs. I'd like to do something (as CAs) to remediate the issue. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Monday, March 7, 2016 4:04 AM To: Jeremy Rowley Cc: mozilla-dev-security-pol

RE: More SHA-1 certs

2016-03-04 Thread Jeremy Rowley
. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Friday, March 4, 2016 2:20 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org; sanjay_m...@symantec.com Subject: Re: More SHA-1 certs On 04/03/16 04:18, Jeremy Rowley wrote: > If you rec

RE: SHA-1 S/MIME certificates

2016-04-04 Thread Jeremy Rowley
ty-policy > [mailto:dev-security-policy-bounces+varga.viktor=netlock...@lists.mozi > lla.org] On Behalf Of Jeremy Rowley > Sent: Wednesday, March 30, 2016 10:54 PM > To: Jakob Bohm <jb-mozi...@wisemo.com>; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: RE: SHA-1

RE: Which intermediate certs to add to CA Community in Salesforce

2016-04-13 Thread Jeremy Rowley
EmailProtection should be a lower class citizen. It's not heavily used by Mozilla and doesn't have the same risk to the community of misuse. There also aren't very stringent requirements surrounding the operation of emailprotection intermediates and certificates. There simply aren't applicable

RE: Other Curves

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

RE: Other Curves

2017-02-01 Thread Jeremy Rowley
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

RE: Other Curves

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

RE: Other Curves

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

RE: Other Curves

2017-02-01 Thread Jeremy Rowley
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

Other Curves

2017-02-01 Thread Jeremy Rowley
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

RE: Other Curves

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

RE: Certificate validation phishing

2017-01-23 Thread Jeremy Rowley
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Nick Lamb Sent: Monday, January 23, 2017 3:42 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificate validation phishing On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley wrote

RE: I found some SHA-1 certificates issued by Symantec

2017-01-24 Thread Jeremy Rowley
I disagree. If the CA has requested removal of the root and added it to OneCRL, then I don't see how there is an obligation to continue operating the root under the Mozilla policy. If the browser doesn't update the root store/revocation list to remove the root, then the browser is accepting the

RE: Appropriate role for lists of algorithms and key sizes

2017-01-24 Thread Jeremy Rowley
Why not just make the changes at the CAB Forum? That's the purpose of the CAB Forum afterall - to discuss these policies. Seems like it would be better to add restrictions there first before creating a separate policy. -Original Message- From: dev-security-policy

RE: Test Certificates from Verizon

2017-01-30 Thread Jeremy Rowley
...@lists.mozilla.org Subject: Re: Test Certificates from Verizon On Monday, January 30, 2017 at 11:27:39 AM UTC-8, Kathleen Wilson wrote: > On Monday, January 30, 2017 at 11:13:43 AM UTC-8, Jeremy Rowley wrote: > > Based on the Symantec disclosure, we ran a test on our own certs >

Test Certificates from Verizon

2017-01-30 Thread Jeremy Rowley
Based on the Symantec disclosure, we ran a test on our own certs (including cross-signed partners) and found the following certificates that were issued contrary to the Baseline Requirements. All of these certificates were issued by Verizon's subordinate certificate. We've requested that the

RE: Certificate validation phishing

2017-01-23 Thread Jeremy Rowley
What do you mean they are weak sauce? Considering at least one of the patents is claimed to cover the ACME challenge validations, they seem pretty on-point. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

2016-09-06 Thread Jeremy Rowley
BRs require revocation within 24 hours of notice. It's a terrible timeline but one the browsers have strictly enforced for even wide spread deployments. > On Sep 6, 2016, at 4:30 PM, Steve Medin wrote: > > We have become aware of this certificate and its key

Re: Reuse of serial numbers by StartCom

2016-09-01 Thread Jeremy Rowley
The ballot on this started today > On Sep 1, 2016, at 7:21 AM, Kurt Roeckx wrote: > >> On 2016-09-01 14:21, Matt Palmer wrote: >>> On Thu, Sep 01, 2016 at 10:53:36AM +0300, Eddy Nigg wrote: On 09/01/2016 04:20 AM, Matt Palmer wrote: You were knowingly violating a MUST

RE: Incidents involving the CA WoSign

2016-08-24 Thread Jeremy Rowley
Gerv, On incident 0, its unclear whether a cert was actually mis-issued. Although they used a higher level port, did the researcher successfully bypass WoSign's domain validation process? Is the only concern that WoSign permitted higher level ports? On incident 1, I agree this was a bad

RE: Incidents involving the CA WoSign

2016-08-24 Thread Jeremy Rowley
t;g...@mozilla.org> Cc: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang <rich...@wosign.com> Subject: Re: Incidents involving the CA WoSign On Wed, Aug 24, 2016 at 9:30 AM, Gervase Markham <g...@mozilla.org> wrote: >

RE: Incidents involving the CA WoSign

2016-08-24 Thread Jeremy Rowley
: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley Sent: Wednesday, August 24, 2016 1:41 PM To: Peter Bowen <pzbo...@gmail.com>; Gervase Markham <g...@mozilla.org> Cc: Richard Wang <rich...@wosign.com>; mo

RE: Comodo issued a certificate for an extension

2016-10-03 Thread Jeremy Rowley
No. The definition of Authorization Domain Name allows a CA to issue www.example.com if the CA can prove control over example.com. However, the reverse is not true. Proving control over www.example.com does not validate example.com. -Original Message- From: dev-security-policy

RE: Technically Constrained Sub-CAs and the BRs

2016-10-26 Thread Jeremy Rowley
One thing I forgot to mention: Although I think Viriginia's view of the process is fine, passing the ballot now puts the requirement into a weird status where it may be adopted or not adopted, depending on the CA's interpretation on when changes are adopted. This then becomes an exercise in

RE: Update on transition of the Verizon roots and issuance of SHA1 certificates

2016-11-04 Thread Jeremy Rowley
Thanks Peter for the questions. The answers are listed below: First, a couple of questions about DigiCert itself. The press release at https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-majority-stake-in-digicert/ says that Thoma Bravo acquired a majority stake in DigiCert

  1   2   3   4   >