RE: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

Should this limit on reuse also apply to s/MIME? Right now, the 825 day limit in Mozilla policy only applies to TLS certs with email verification of s/MIME being allowed for infinity time. The first draft of the language looked like it may change this while the newer language puts back the TLS

RE: Mandatory reasonCode analysis

.@lists.mozilla.org>> on behalf of Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> Sent: 30 September 2020 17:41 To: Mozilla mailto:mozilla-dev-security-pol...@lists.mozilla.org>> Subject: RE: Mandatory reasonCode analysis CAUTION: This ema

RE: Mandatory reasonCode analysis

This is a good question. I read the requirements as applying only to CRLs and OCSP published after the effective date since the BRs always say explicitly when they apply to items before the effective date. I also read this language: If a CRL entry is for a Certificate not subject to these

RE: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

:51 AM To: Jeremy Rowley Cc: Mozilla Subject: Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs On Thu, Jul 2, 2020 at 1:33 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Threatening distrus

RE: Question about the issuance of OCSP Responder Certificates by technically constrained CAs

Threatening distrust over a discussion about applicability of requirements seems contrary to Mozilla's open discussion policy, and I don't think that should be an answer while there are still open questions about the language in 4.9.9. Separating out the security risk from the applicability of

RE: Clear definition of a "locality"

That's accurate, but the real question goes back to a discussion we previously had at the CAB forum that I don't think was answered - what is a locality vs. a state vs. an address? In Sept 2019, we put in code that requires this be checked against however map software defines it, allowing

Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

. Very top of the page ;) e.g. https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl=Mozilla=Server+Authentication=v=2 On Wed, Jun 17, 2020 at 5:18 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Is there a way to filter out the rev

RE: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

Is there a way to filter out the revoked and non-TLS/SMIME ICAs? -Original Message- From: dev-security-policy On Behalf Of Rob Stradling via dev-security-policy Sent: Wednesday, June 17, 2020 5:07 AM To: dev-security-policy Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA

RE: GoDaddy: Failure to revoke certificate with compromised key within 24 hours

Yes - that's been well established. See https://bugzilla.mozilla.org/show_bug.cgi?id=1639801 (where Ryan reminded me that this has been discussed and resolved with actual language in the BRs) -Original Message- From: dev-security-policy On Behalf Of Kurt Roeckx via dev-security-policy

RE: Status of the bugzilla bug list

) -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Monday, May 18, 2020 1:52 PM To: Mozilla Subject: RE: Status of the bugzilla bug list I think your list of 23 is wrong. For example, bug 1550645 is just waiting for Mozilla closure

RE: Status of the bugzilla bug list

I think your list of 23 is wrong. For example, bug 1550645 is just waiting for Mozilla closure. It looks like 1605804 is in the same boat. -Original Message- From: dev-security-policy On Behalf Of Matthias van de Meent via dev-security-policy Sent: Monday, May 18, 2020 1:04 PM To: MDSP

RE: Digicert issued certificate with let's encrypts public key

encrypts public key Jeremy Rowley via dev-security-policy writes: >For those interested, the short of what happened is that we had an old >service where you could replace existing certificates by having >DigiCert connect to a site and replace the certificate with a key taken >from th

RE: Digicert issued certificate with let's encrypts public key

I thought I posted on this a while ago, but I can't seem to find the post. It may have been CAB Forum (where the archives are nearly useless). The conclusion from that is the CSR isn't required as part of the issuance process because there isn't a risk without having actual control over the

RE: CT2 log signing key compromise

Yes, but only for embedded SCTs. For revocation or extension served SCTs, you could end up with different timestamps depending on how the CA is set up. On top of that, for embedded SCTs, you'd need to route the cert through a separate singing service that used the compromised key. For that to

RE: CT2 log signing key compromise

to other DigiCert infrastructure. Thanks, Ian Carroll On Sun, May 3, 2020 at 4:19 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt ro

RE: CT2 log signing key compromise

Cc: Mozilla mailto:mozilla-dev-security-pol...@lists.mozilla.org>> Subject: Re: CT2 log signing key compromise The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jer

RE: CT2 log signing key compromise

if it was included in the tree before that time. However, that is the reason to include multiple SCTs in the same log. -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Sunday, May 3, 2020 5:27 PM To: Alex Cohn Cc: Mozilla Subject: RE: CT2 log

RE: CT2 log signing key compromise

a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt ro

CT2 log signing key compromise

Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt root bug. The remaining logs remain uncompromised and run on separate infrastructure. We discovered the compromise today and are working to turn that log into read only mode so that no new

RE: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

Subject: Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic On Fri, Mar 20, 2020 at 4:15 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: What about issues other than audits? For example, with certain loc

RE: Digicert: failure to revoke certificate with previously compromised key

the disclosures need to be affiliated with actual certs. From: Ryan Sleevi Sent: Monday, March 23, 2020 10:54 AM To: Jeremy Rowley Cc: Matt Palmer ; Mozilla Subject: Re: Digicert: failure to revoke certificate with previously compromised key On Mon, Mar 23, 2020 at 11:01 AM Jeremy Rowley via dev

RE: Digicert: failure to revoke certificate with previously compromised key

Hey Matt, Ryan's post was the part I thought was relevant, but I understood it differently. The cert was issued, but we should have now revoked it (24 hours after receiving notice). I do see your interpretation though, and the language does support 24 hours after issuing the new cert. What I

RE: Digicert: failure to revoke certificate with previously compromised key

That's not the visible consensus IMO. The visible consensus is we need to revoke a cert that is key compromised once we're informed the key is compromised for that cert (https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/1ftkqbsnEU4). The certificate you mentioned was issued

RE: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic

What about issues other than audits? For example, with certain locations closing, key ceremonies may become impossible, leading to downed CRLs/OCSP for intermediates. There's also a potential issue with trusted roles even being able to access the data center if something goes down and Sub CAs

RE: About upcoming limits on trusted certificates

Yeah - I've wanted to do this for a long time. If the domain is only good for 30 days, why would we issue even a 1-year cert? If it's good for 13 months, why not tie the cert validity to that? I guess because they could have transferred the domain (which just means you need additional caps)?

RE: Terms and Conditions that use technical measures to make it difficult to change CAs

Yes - please share the details with me as I am very surprised to hear that. I know the DigiCert agreements I've seen don't permit revocation because of termination so whoever (if anyone) is saying that is contradicting the actual agreement. Threatening revocation because of termination or

RE: About upcoming limits on trusted certificates

I think this statement is not accurate: "As a result, CAs don’t pursue automation, or when they support it, neither promote nor require it." I know very few CAs who want to spend extra resources on manual validations and just as few who don't support some level of automation. The manual methods

RE: DRAFT January 2020 CA Communication

Should anything be mentioned about the allowed algorithms? That's the largest change to the policy and confirming the AlgorithmIdentifiers in each case may take some time. -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Thursday,

RE: Certificate OU= fields with missing O= field

Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: A mistake in the BRs (I wrote the language unfortunately so shame on me for not matching the other sections of org name or the given name). There's no certificate that ever contains all of these field

RE: Certificate OU= fields with missing O= field

A mistake in the BRs (I wrote the language unfortunately so shame on me for not matching the other sections of org name or the given name). There's no certificate that ever contains all of these fields. How would you ever have that? There's no requirement that the OU field information relate

RE: Mozilla Policy Requirements CA Incidents

I like this approach. You could either add a page in the policy document or include the information in the management assertion letter (or auditor letter) that gives information about the auditor’s credentials and background. I also like the idea of summary on what the auditor followed up on

DNS records and delegation

Question, is there any prohibition against demonstration of domain control being delegated to a third party or even the CA itself? I don't think so, but figured we've discussed differences in interpretation a lot lately so wanted to see if people agreed. Section 3.2.2.4.7 in the CAB/F

RE: Mozilla Policy Requirements CA Incidents

I think requiring publication of profiles for certs is a good idea. It’s part of what I’ve wanted to publish as part of our CPS. You can see most of our profiles here: https://content.digicert.com/wp-content/uploads/2019/07/Digicert-Certificate-Profiles.pdf, but it doesn’t include ICAs right

RE: Mozilla Policy Requirements CA Incidents

Tackling Sub CA renewals/issuance from a compliance perspective is difficult because of the number of manual components involved. You have the key ceremony, the scripting, and all of the formal process involved. Because the root is stored in an offline state and only brought out for a very

RE: Mozilla Policy Requirements CA Incidents

Speaking from a personal perspective - This all makes sense, and, to be honest, the spectrum/grade idea isn’t a good or robust. Implementing something like that requires too many judgment questions about whether a CA belongs in box x vs. box y and what is the difference between those two

RE: Mozilla Policy Requirements CA Incidents

Interesting. I can't tell with the Netlock certificate, but the other three non-EKU intermediates look like replacements for intermediates that were issued before the policy date and then reissued after the compliance date. The industry has established that renewal and new issuance are

RE: CAs cross-signing roots whose subjects don't comply with the BRs

-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Monday, October 7, 2019 10:21 AM To: r...@sleevi.com Cc: mozilla-dev-security-policy Subject: RE: CAs cross-signing roots whose subjects don't comply with the BRs Yeah - I like the visibility here since I know I often forget to post

RE: CAs cross-signing roots whose subjects don't comply with the BRs

Yeah - I like the visibility here since I know I often forget to post the incident to the Mozilla list as well as post the bug. IMO - it's up to the CA to decide if they want to sign something in violation of the BRs and then it's up the browsers on what the action taken in response is. I

RE: CAs cross-signing roots whose subjects don't comply with the BRs

Are both roots trusted in the Mozilla root store? If so, could you say that Mozilla has approved of the root not-withstanding the non-compliance? If root 2 did go through the public review process and had the public look at the certificate and still got embedded, then Mozilla perhaps signed off

RE: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

r customers, such as for white label CAs. So that’s why I’m struggling to understand the use case, or the challenges, with at least requiring domain-part validation by the CA. On Fri, Oct 4, 2019 at 8:09 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.

RE: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

I did flag that part as wearing my personal hat . The Trust Italia Sub CA is an example of where confusion may arise in the policy and where the complexity arises in these relationships. This was not necessarily a “new” CA from what I understood. This is also why I qualified the shut down in

RE: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates

Will this permit either verification of the email address or the domain part? For example, some organizations may verify their entire domain space and then confirm contractors using a random value sent to the email address itself. They don't need the entire domain space in those cases, but

RE: OCSP responder support for SHA256 issuer identifier info

(And, for the record, none of that legacy infrastructure that would Ryan mentions taking years to update exists anymore. Yay for shutting down legacy systems!) -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Friday, October 4, 2019

RE: OCSP responder support for SHA256 issuer identifier info

The CAB forum specifies that OCSP responses MUST conform to RFC5019 or RFC 6960. The requirements do not specific which RFC to follow when processing requests, but I think you can imply that either one is required, right? Section 2.1.1. specifies that: Clients MUST use SHA1 as the hashing

RE: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Hey Wayne, I think there might be confusion on how the notification is supposed to happen. Is notification through CCADB sufficient? We've uploaded all of the Sub CAs to CCADB including the technically constrained ICAs. Each one that is hosted/operated by itself is marked that way using the

RE: Next Root Store Policy Update

One suggestion on incident reports is to define "regularly update" as some period of time as non-responses can result in additional incident reports. Maybe something along the lines of "the greater of every 7 days, the time period specified in the next update field by Mozilla, or the time

RE: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

I'm surprised any CA has heartburn over the EKU changes. Microsoft has required them in end entity certificates for quite some time. From the MS policy: "Effective February 1, 2017, all end-entity certificates must contain the EKU for the purpose that the CA issued the certificate to the

RE: DigiCert OCSP services returns 1 byte

09 PM Jeremy Rowley via dev-security-policy > < dev-security-policy@lists.mozilla.org> wrote: > > > This means, for example, that (i) a CA must provide OCSP services > > and responses in accordance with the Mozilla policy for all > > pre-certificates > as > &

RE: DigiCert OCSP services returns 1 byte

, 2019 9:25 AM To: Jeremy Rowley Cc: Wayne Thayer ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert OCSP services returns 1 byte On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: This means, for e

Re: DigiCert OCSP services returns 1 byte

> issuing a corresponding certificate. > I plan to add this to the wiki next week. I also plan to include this in in a future update to our Root Store Policy. I will greatly appreciate your constructive feedback on this proposal. - Wayne [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Pr

RE: DigiCert OCSP services returns 1 byte

> I plan to add this to the wiki next week. I also plan to include this in in a future update to our Root Store Policy. I will greatly appreciate your constructive feedback on this proposal. - Wayne [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices [2] https://cabforum.org/pi

EV Jurisdiction of Incorporation

Hi Everyone, One of my goals at DigiCert is provide greater transparency. One of the ideas I’ve kicked around is community-drive EV or EV transparency. To start that off, I thought I’d share the sources we use verification of the jurisdiction of incorporation/registration here. This list is

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

Obviously I think good is the best answer based on my previous posts. A precert is still a cert. But I can see how people could disagree with me. From: dev-security-policy on behalf of Jeremy Rowley via dev-security-policy Sent: Saturday, August 31, 2019 9:05

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

I dont recall the cab forum ever contemplating or discussing ocsp for precertificates. The requirement to provide responses is pretty clear, but what that response should be is a little confusing imo. From: dev-security-policy on behalf of Tomas Gustavsson via

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

” for Some Precertificates On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Is our answer right though? I wasn't sure. I said "Good" because "a promise to issue a cert" could be considered the same is

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Is our answer right though? I wasn't sure. I said "Good" because "a promise to issue a cert" could be considered the same issued. In that case the BRs say you must respond good. Ci

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

>From RFC6962: “As above, the Precertificate submission MUST be accompanied by the Precertificate Signing Certificate, if used, and all additional certificates required to verify the chain up to an accepted root certificate. The signature on the TBSCertificate indicates the certificate

RE: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

Is our answer right though? I wasn't sure. I said "Good" because "a promise to issue a cert" could be considered the same issued. In that case the BRs say you must respond good. However, if "a promise to issue a certificate" is not the same as issuance, the BRs don't apply to the OCSP until the

RE: DigiCert OCSP services returns 1 byte

P services for the pre-cert. The reason is Mozilla requires an OCSP for each end-entity certificate listing an AIA in the certificate. Pre-certs are end-entity certificates. Jeremy -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent

Re: DigiCert OCSP services returns 1 byte

:38 AM Ryan Sleevi via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: > Thanks for p

Re: DigiCert OCSP services returns 1 byte

OCSP services returns 1 byte To: Jeremy Rowley Cc: Curt Spann, mozilla-dev-security-pol...@lists.mozilla.org On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Thanks for posting this Curt. We investigated and

RE: DigiCert OCSP services returns 1 byte

Thanks for posting this Curt. We investigated and posted an incident report on Bugzilla. The root cause was related to pre-certs and an error in generating certificates for them. We're fixing the issue (should be done shortly). I figured it'd be good to document here why pre-certs fall under

RE: Symantec migration update

Yeah - these types of weird continuity requirements are all over the place and the reason the consolidation has taken this long. A lot of the effort has been trying to figure out how to replace things tied to old hardware with updated systems, essentially rebuilding things (like the timestamp

Symantec migration update

Hey – I realized it’s been a long time since I posted an update about where we are at on shutting down the legacy Symantec systems. I thought the community might find it interesting on what we’re doing to consolidate all the system. When we bought the Symantec CA business, we promised to bring

RE: GlobalSign: SSL Certificates with US country code and invalid State/Prov

I've always thought the reason OV/EV ballots haven't been proposed/passed is combination of a lack of interest from the browsers and the fact that governance reform seems to get in the way of everything else. I've for proposed tons of things over the years that simply fail because I can't get

RE: DigiCert OCSP services returns 1 byte

Our super unpublished RFC. Sadly no. We're still investigating, but it looks like it has to do with pre-certs and the way the system responds if when the actual cert never issued. We're working on an incident report. Funny enough (and not in the ha-ha way), the system works if the pre-cert

RE: Jurisdiction of incorporation validation issue

>> 1. I believe the BRs and/or underlying technical standards are very clear if the ST field should be a full name ("California") or an abbreviation ("CA"). This is only true of the EV guidelines and only for Jurisdiction of Incorporation. There is no formatting requirement for place of

RE: Jurisdiction of incorporation validation issue

>> I'm a little nervous about encouraging wide use of OCR. You may recall at >> least one CA was bit by an issue in which their OCR system misidentified >> letters - https://bugzilla.mozilla.org/show_bug.cgi?id=1311713 >> That's why I was keen to suggest technical solutions which would verify

RE: Jurisdiction of incorporation validation issue

* Could you highlight a bit more your proposal here? My understanding is that, despite the Handelsregister ("Commercial Register") being available at a country level, it's further subdivided into a list of couunty or region - e.g. the Amtsgericht Herne ("Local Court Herne"). * It

Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

I only know because I was looking at this issue tonight as well to add an update later to the joi bug I posted. From: dev-security-policy on behalf of Jeremy Rowley via dev-security-policy Sent: Thursday, August 22, 2019 9:07:51 PM To: Corey Bonnell ; Doug

Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

It's a trap. I do wish memes showed up here Censys shows something like 130 globalsign certs with abbreviated joi info. I think we show 16? From: dev-security-policy on behalf of Corey Bonnell via dev-security-policy Sent: Thursday, August 22, 2019

Jurisdiction of incorporation validation issue

I posted this tonight: https://bugzilla.mozilla.org/show_bug.cgi?id=1576013. It's sort of an extension of the "some-state" issue, but with the incorporation information of an EV cert. The tl;dr of the bug is that sometimes the information isn't perfect because of user entry issues. What I was

RE: CA handling of contact information when reporting problems

I'm not sure there should be a strict requirement that you can't provide that communication (sometimes there is good reason to get people talking together). However, we don't forward this information as policy because we like to get the reports. Anything that ends up stifling getting the

RE: Auditor letters and incident reports

Full disclosure - this was not my idea, but I thought it was a really good one and worth bringing up here. -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Wednesday, August 21, 2019 10:46 PM To: mozilla-dev-security-policy Subject

Auditor letters and incident reports

Hey all, An interesting issue came up recently with audits. Because the Mozilla policy includes some requirements that diverge from the BRs, the audit criteria don't necessarily cover everything Mozilla cares about. Thus, it's possible to have an incident that doesn't show up on an audit. It's

RE: Change in control event at DigiCert

Thoma Bravo will no longer be involved once the deal happens. From: Ryan Sleevi Sent: Thursday, July 18, 2019 3:30 PM To: Jeremy Rowley Cc: mozilla-dev-security-policy Subject: Re: Change in control event at DigiCert On Wed, Jul 17, 2019 at 8:09 PM Jeremy Rowley via dev-security

Change in control event at DigiCert

Just FYI, there is an upcoming change in control event that will happen at DigiCert where TA and Clearlake will take equity ownership of the company. TA is currently a minority shareholder in DigiCert. Details are posted here: https://www.pehub.com/2019/07/clearlake-and-ta-to-invest-in-digicert/.

RE: Logotype extensions

The language of the BRs is pretty permissive. Assuming Mozilla didn't update its policy, then issuance would be permitted if the CA can show that the following was false: b. semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as

Re: Logotype extensions

I think my biggest concern is that there hasn't actual been any proof that this would mislead relying parties. You'd actual have to have Mozilla do something with it first. The general badness can apply to any extension in a cert. No actual risk has been pointed out other than a CA may put

Re: Logotype extensions

That argument applies to every extension not expressly permitted by the BRs. Even if I just put a number in s private extension, a relying party could be led to think jts their age. Can we better define what could constitute as potentially misleading extensions? Without that definition, this

Logotype extensions

We wanted to experiment a bit with logotype extensions and trademarks, but we heard from the CAB Forum that whether inclusion is allowed is subject a bit to interpretation by the browsers. >From the BRs section 7.1.2.4 "All other fields and extensions MUST be set in accordance with RFC 5280.

RE: DigiCert validation issue

Here's the link: https://bugzilla.mozilla.org/show_bug.cgi?id=1556948 -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Wednesday, June 5, 2019 12:17 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: DigiCert validation

DigiCert validation issue

I just posted this incident report. The summary is we had an issue where a certain path allowed issuance of certs for example.com when only www.example.com was verified. This incident happened previously with Comodo here:

RE: CAA record checking issue

The difference is we actually have the data at time of issuance. It just wasn’t correctly relied on for these specific certs. I think this means there is an open question on whether the issuance even was a mis-issuance since the CAA information was collected…even if it wasn’t perfect. This

RE: CAA record checking issue

: CAA record checking issue On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a ne

RE: CAA record checking issue

PM, "dev-security-policy on behalf of Jeremy Rowley via dev-security-policy" wrote: FYI, we posted this today: https://scanmail.trustwave.com/?c=4062=99zU3MWO5ZnJnVq-TZZut0-4BjNGA3S27plK9QDITw=5=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid

Re: CAA record checking issue

Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissu

CAA record checking issue

FYI, we posted this today: https://bugzilla.mozilla.org/show_bug.cgi?id=1550645 Basically we discovered an issue with our CAA record checking system. If the system timed out, we would treat the failure as a DNS failure instead of an internal failure. Per the BRs Section 3.2.2: "CAs are

RE: Reported Digicert key compromise but not revoked

No argument from me there. We generally act on them no matter what. Typically any email sent to supp...@digicert.com requesting revocation is forwarded to rev...@digicert.com. That's the standard procedure. This one was missed unfortunately. -Original Message- From: dev-security-policy

RE: Reported Digicert key compromise but not revoked

Thanks Wayne. We’ll update our CPS to keep it clear. From: Wayne Thayer Sent: Thursday, May 9, 2019 5:04 PM To: Andrew Ayer Cc: Jeremy Rowley ; Jeremy Rowley via dev-security-policy Subject: Re: Reported Digicert key compromise but not revoked DigiCert CPS section 1.5.2 [1] could also

RE: Reported Digicert key compromise but not revoked

Thanks Andrew. Yes - it should be rev...@digicert.com -Original Message- From: Andrew Ayer Sent: Thursday, May 9, 2019 4:46 PM To: Jeremy Rowley Cc: Jeremy Rowley via dev-security-policy Subject: Re: Reported Digicert key compromise but not revoked On Thu, 9 May 2019 14:47:05 +

RE: Reported Digicert key compromise but not revoked

Hi Han - the proper alias is rev...@digicert.com. The support alias will sometimes handle these, but not always. We picked up the request from your post here and are working on it. Of course, this is out of scope of the Mozilla policy since its code signing only. -Original Message-

RE: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates

I think it should be added by Mozilla. The CAB Forum is a long way from having an s/MIME policy in place (there's not even a working group yet). Having no policy for cert revocation related to s/MIME ignores that s/MIME are part of the Mozilla ecosystem and sequesters them from the rest of the

RE: Arabtec Holding public key? [Weird Digicert issued cert]

A possibility. They could have pasted something in the root chain. Note that the required handshake would have caught that if it'd been implemented. Overall it doesn't matter too much if was malicious or innocent, the cert holder can't do anything without the private key. -Original

RE: Arabtec Holding public key? [Weird Digicert issued cert]

path because we figured the issuance of these certs created a potential PR concern, even if there isn't a real security risk. -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Jeremy Rowley via dev-security-policy Sent: F

RE: Arabtec Holding public key? [Weird Digicert issued cert]

shutting off the no-CSR path because we figured the issuance of these certs created a potential PR concern, even if there isn't a real security risk. -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Friday, April 12, 2019 10:56 AM

RE: Arabtec Holding public key? [Weird Digicert issued cert]

I don't mind filling in details. We have a system that permits creation of certificates without a CSR that works by extracting the key from an existing cert, validating the domain/org information, and creating a new certificate based on the contents of the old certificate. The system was

RE: Pre-Incident Report - GoDaddy Serial Number Entropy

No one wants to paint a target on their back. If I announce we're 100% compliant with everything, that's asking to be shot in the face. You're welcome to look at ours. I think we fully comply with 7.1 (I've double checked everything) and would love to find out if we're not. I like the feedback and

RE: GoDaddy Revocation Disclosure

the incident. Jeremy From: Ryan Sleevi Sent: Tuesday, March 12, 2019 2:31 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: GoDaddy Revocation Disclosure On Tue, Mar 12, 2019 at 4:17 PM Jeremy Rowley via dev-security-policy mailto:dev-security

RE: GoDaddy Revocation Disclosure

One item that I think could bear a useful discussion from these incident reports is how the community can get more involved in discussing and helping with incident reports. For example, the 63 bit serial number issue is leading to a lot of certs potentially being revoked with little benefit to

  1   2   3   >