RE: Updating CA:SubordinateCA_checklist

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?

+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

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

: 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

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

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

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: DRAFT: May CA Communication

=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

-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

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

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

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

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

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

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.

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.

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

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.

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

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

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

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

RE: Code Signing Draft

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

...@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: [FORGED] Name issues in public certificates

...@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

* 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

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

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

...@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

: 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

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

...@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

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

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: SHA-1 S/MIME certificates

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

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

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

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)

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

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

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

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

...@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

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

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

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

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

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

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

[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

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

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

...@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

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

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)

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

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

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

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

: 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

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

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

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

RE: Mozilla CT Policy

This is awesome. We're very excited to see Mozilla support CT. How about: 1) What version of logs should Mozilla accept (do they have to comply with the bis)? If they are compliant with the original spec, should they be accepted until a certain date when they must transition to the new bis? 2)

RE: Can we require id-kp-serverAuth now?

7.1.2.3 requires an EKU but does not require serverAuth. clientAuth is permissible. Omitting other values is only a "SHOULD" This is back to the same problem we keep going round and round again. Only certificates intended for web servers are considered in scope of the BRs. Therefore, the BRs only

RE: Can we require id-kp-serverAuth now?

Perhaps the CA didn't intend them to be used for Web PKI, making them out of scope of the BRs. Playing devil's advocate, I'd say anything issued without serverAuth isn't intended to be used for server authentication by the CA. Because of this, either the CAB Forum should define all certs with

Re: Technically Constrained Sub-CAs

So much has changed since the last time we discussed shorter validity periods at CAB forum that it'd be worth bringing up again. I think the vocal minority opposed the change last time and they may have switched positions by now. > On Nov 18, 2016, at 7:12 AM, Gervase Markham

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

Resent without a signature Hi everyone, This email is intended to gather public and browser feedback on how we are handling the transitioning Verizon's customers to DigiCert and share with everyone the plan for when all non-DigiCert hosted sub CAs will be fully compliant with the BRs

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

+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Han Yuwei Sent: Thursday, November 3, 2016 6:14 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates 在 2016年11月4日星期五 UTC+8上午3:52:23，Jeremy Rowley写道

RE: Cerificate Concern about Cloudflare's DNS

Revocation support for non-subscribers is sort of implied...sort of: Section 4.9.3: The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other

RE: Cerificate Concern about Cloudflare's DNS

Message- From: Tom Ritter [mailto:t...@ritter.vg] Sent: Wednesday, November 2, 2016 10:45 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Peter Bowen <pzbo...@gmail.com>; mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm <jb-mozi...@wisemo.com> Subject: Re:

RE: Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

I agree with this approach. Nothing of note was include after the domain validation passed so making 1.3.7 the effective version makes sense. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of

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

this. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Monday, January 9, 2017 9:28 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certif

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

on transition of the Verizon roots and issuance of SHA1 certificates On 2017-01-09 17:28, Rob Stradling wrote: > On 03/11/16 19:34, Jeremy Rowley wrote: > > > Hi Jeremy. > >> 7. The Belgium government is our biggest challenge in migrating >> Verizon customers. With over

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

It probably should not be same as parent. Ben will update it. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Monday, January 9, 2017 10:02 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re:

Re: Misissued/Suspicious Symantec Certificates

Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results. Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point. > On Feb 22, 2017, at 8:33 PM, Ryan

  1   2   3   4   >