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

[Jeremy Rowley via dev-security-policy]

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 customer, and the 
end-entity certificate may not use “any EKU.”" There's a chance that the CA is 
not in Microsoft, but I thought Mozilla usually had fewer CAs than Microsoft 
included. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, October 2, 2019 6:05 PM
To: horn...@gmail.com
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates

On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道：
> > The BRs require EKUs in leaf TLS certs, but there is no equivalent 
> > requirement for S/MIME certificates. This leads to confusion such as 
> > [1]
> in
> > which certificates that are not intended for TLS or S/MIME fall 
> > within
> the
> > scope of our policies.
> >
> > Simply requiring EKUs in S/MIME certificates won't solve the problem
> unless
> > we are willing to exempt certificates without an EKU from our 
> > policies,
> and
> > doing that would create a rather obvious loophole for issuing S/MIME 
> > certificates that don't adhere to our policies.
> >
> > The proposed solution is to require EKUs in all certificates that 
> > chain
> up
> > to roots in our program, starting on some future effective date (e.g.
> April
> > 1, 2020). This has the potential to cause some compatibility 
> > problems
> that
> > would be difficult to measure and assess. Before drafting language 
> > for
> this
> > proposal, I would like to gauge everyone's support for this proposal.
> >
> > Alternately, we could easily argue that section 1.1 of our existing
> policy
> > already makes it clear that CAs must include EKUs other than 
> > id-kp-serverAuth and id-kp-emailProtection in certificates that they 
> > wish to remain out of scope for our policies.
> >
> > This is https://github.com/mozilla/pkipolicy/issues/163
> >
> > I will greatly appreciate everyone's input on this topic.
> >
> > - Wayne
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221
>
>
> GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates 
> However, the influence range of implementation is very large.
> We need to define our own Document Signing EKU and data encryption 
> EKU, and coordinate all subordinate Cas(Five CAs) and application 
> system’s owners(more than 2,000 application systems).
> It needs a whole year to implement this. Therefore, after multiple 
> evaluations, it is decided to officially add the EKU to the user 
> certificate on January 1, 2021.
> It is difficult for us to complete ahead of April 2020.
> Can we get more buffer?
>
>
I had expected to have this policy update completed sooner when I proposed 
April 2020 as the date for requiring EKUs in end-entity certificates. Given 
that, I think it's reasonable to push the date back to July 2020, but not to 
January 2021. 2021 seems particularly unreasonable in light of the Microsoft 
requirement [1] that went into effect in January 2017 and appears to apply to 
GPKI.

Will any other CAs find it impossible to meet this requirement for certificates 
issued after June 2020? Also, are there any concerns with this applying to 
certificates issued from technically constrained intermediate CA certificates? 
As-proposed, this applies to those certificates (and it appears to me that 
Microsoft's policy does as well).

- Wayne

[1]
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Next Root Store Policy Update

[Jeremy Rowley via dev-security-policy]

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 period for 
the next update as agreed upon with Mozilla". I'd also change "the 
corresponding bug is resolved by a Mozilla representative" to "the 
corresponding bug is marked as resolved in bugzilla by a Mozilla 
representative" since the CA is resolving the actual bug, and Mozilla is 
managing its perception on the bug's status.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, October 2, 2019 4:17 PM
To: mozilla-dev-security-policy 
Subject: Re: Next Root Store Policy Update

Over the past 3 months, a number of other projects distracted me from this 
work. Now I'd like to focus on finishing these updates to our Root Store 
policy. There are roughly 6 issues remaining to be discussed, and I will, as 
always, greatly appreciate everyone's input on them. I'll be sending out 
individual emails on each issue.

Meanwhile, you can view a redline of the changes we previously agreed on:
https://github.com/mozilla/pkipolicy/compare/master...2.7

- Wayne

On Wed, Mar 27, 2019 at 4:12 PM Wayne Thayer  wrote:

> I've added a few more issues that were recently created to the list 
> for
> 2.7: https://github.com/mozilla/pkipolicy/labels/2.7
>
> 176 - Clarify revocation requirements for S/MIME certs
> 175 - Forbidden Practices wiki page says email validation cannot be 
> delegated to 3rd parties
>
> I plan to begin posting issues for discussion shortly.
>
>
> On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer  wrote:
>
>> Later this month, I would like to begin discussing a number of 
>> proposed changes to the Mozilla Root Store policy [1]. I have 
>> reviewed the list of issues on GitHub and labeled the ones that I recommend 
>> discussing:
>> https://github.com/mozilla/pkipolicy/labels/2.7 They are:
>>
>> 173 - Strengthen requirement for newly included roots to meet all 
>> current requirements
>> 172 - Update section 5.3 to include Policy Certification Authorities 
>> as an exception to the mandatory EKU inclusion requirement
>> 171 - Require binding of CA certificates to CP/CPS
>> 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair 169, 
>> 140 - Extend Section 8 to also encompass subordinate CAs 168, 161, 
>> 158  - Require Incident Reports, move practices into policy
>> 163 - Require EKUs in end-entity certificates (S/MIME)
>> 162 - Require disclosure of CA software vendor/version in incident 
>> report
>> 159 - Clarify section 5.3.1 Technically Constrained
>> 152 - Add EV audit exception for policy constrained intermediates
>> 151 - Change PITRA to Point-in-Time assessment in section 8
>>
>> I will appreciate any feedback on the proposed list of issues to discuss.
>>
>> I do recognize that the current DarkMatter discussions could result 
>> in the need to add some additional items to this list.
>>
>> I have created a new branch for drafting these changes [1] and made 
>> one commit that adds a bullet to the BR Conformance section informing 
>> the reader that Mozilla policy has a more restrictive list of 
>> approved algorithms [3]
>>
>> As we've done in the past, I plan to post individual issues for 
>> discussion in small batches over the next few months, with the goal 
>> of finalizing version 2.7 by June.
>>
>> - Wayne
>>
>> [1]
>> https://www.mozilla.org/en-US/about/governance/policies/security-grou
>> p/certs/policy/ [2] 
>> https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md
>> [3] https://github.com/mozilla/pkipolicy/issues/167
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 Subordinate CA Owner 
field. Section 8 links to emailing certifica...@mozilla.org but operationally, 
CCADB has become the default means of providing this notice. If you're 
expecting email, that may be worth clarifying in case CAs missed that an email 
is required. I know I missed that, and because CCADB is the common method of 
notification there is a chance that notice was considered sent but not in the 
expected way. 

There's also confusion over the "new to Mozilla" language I think. I 
interpreted this language as organizations issued cross-signs after the policy. 
For example, Siemens operated a Sub CA through Quovadis prior to policy date so 
they aren't "new" to the CA space even if they were re-certified. However, they 
would be new in the sense you identified - they haven't gone through an 
extensive review by the community.  If the goal is to ensure the community 
review happens for each Sub CA, then requiring all recertifications to go 
through an approval process makes sense instead of making an exception for new. 
I'm not sure how many exist currently, but if there are not that many 
organizations, does a grandfathering clause cause unnecessary complexity? I 
realize this is not in DigiCert's best interest, but the community may benefit 
the most by simply requiring a review of all Sub CAs instead of trying to 
grandfather in existing cross-signs.  Do you have an idea on the number that 
might entail
 ? At worst, we waste a bunch of time discovering that all of these are 
perfectly operated and that they could have been grandfathered in the first 
place. At best, we identify some critical issues and resolve them as a 
community. 

If there are a significant number of unconstrained on-prem CAs, then language 
that requires a review on re-signing would be helpful.  Perhaps say "As of X 
date, a CA MUST NOT sign a non-technically constrained certificate where 
cA=True for keys that are hosted external to the CA's infrastructure or that 
are not operated in accordance with the issuing CA's policies and procedures 
unless Mozilla has first granted permission for such certificate"? The wording 
needs work of course, but the idea is that they go through the discussion and 
Mozilla signs off. A process for unconstrained Sub CAs that is substantially 
similar to the root inclusion makes sense, but there is documentation on CCADB 
for the existing ones. Still, this documentation should probably made 
available, along with the previous incident reports, to the community for 
review and discussion. Afterall, anything not fully constrained is essentially 
operating the same as a fully embedded root.

Speaking on a personal, non-DigiCert note, I think on-prem sub CAs are a bad 
idea, and I fully support more careful scrutiny on which entities are 
controlling keys. Looking at the DigiCert metrics, the on-prem Sub CAs are 
responsible for over half of the incident reports, with issues ranging from 
missed audit dates to incorrect profile information. The long cycle in getting 
information,  being a middle-man information gathering, and trying to convey 
both Mozilla and CAB forum policy makes controlling compliance very difficult, 
and a practice I would not recommend to any CA. Once you've established a 
relationship as a signer CA (or acquired a relationship), extraditing yourself 
is... difficult.  The certificates end up embedded on smart cards, used by 
government institutions and pinned in weird places. And the unfortunate part is 
you don't have the direct relationship with the end-user to offer counsel 
against some of the practices. That extra abstraction layer between the CA and 
root
  store program ends up adding a lot more complexity than you'd initially 
think. Delegating the CA responsibility ends up being a bad idea and takes 
years to fix. DigiCert is finally down to the final few TLS sub CAs (5) and 
each are operating in OCSP signing mode only. They'll all be revoked in 2020. 

Jeremy


-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, October 3, 2019 2:45 PM
To: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

I'd like to revisit this topic because I see it as a significant change and am 
surprised that it didn't generate any discussion.

Taking a step back, a change [1] to notification requirements was made last 
year to require CAs that are signing unconstrained subordinate CAs (including 
cross-certs) controlled by a different organization to notify Mozilla. We have 
received few, if any, notifications of this nature, so I have to wonder if CAs 
are adhering to th

RE: OCSP responder support for SHA256 issuer identifier info

[Jeremy Rowley via dev-security-policy]

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 algorithm for the CertID.issuerNameHash 
and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect 
SHA1 for both fields. Where does the requirement to support SHA256 come in? As 
Ryan mentioned, there was some discussion, but it seems like there was nothing 
settled. I'd support a ballot clarifying the profile, but I don't understand 
the value of requiring both SHA1 and SHA2 signatures for OCSP. Doesn't it just 
make OCSP more cumbersome? 

-Original Message-
From: dev-security-policy  On 
Behalf Of Tomas Gustavsson via dev-security-policy
Sent: Friday, October 4, 2019 1:45 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support 
requests with SHA256 in CertID back in 2014. Not for any relevant security 
reasons, just because some stubborn auditors saw a red flag on the mentioning 
of SHA-1.

We've implemented it by having both hashes in the lookup table where we check 
for issuer when a response comes in. 

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect 
that any client if checking CertID in the response would expect it to match 
what they send. 

I'm suspicious of adding two SingleResponse in the response, one for each 
CertID. 
- Clients are used to one response, they may fail verification if the first one 
doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not 
seem agile.
- It increases the size of responses, we've been told before about the desire 
to keep responses as small as possible (typically to fit in a single etehrnet 
frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:
> Thanks for raising this!
> 
> There some some slight past discussion in the CA/B Forum on this - 
> https://cabforum.org/pipermail/public/2013-November/002440.html - as 
> well as a little during the SHA-1 deprecation discussions ( 
> https://cabforum.org/pipermail/public/2016-November/008979.html ) and 
> crypto agility discussions ( 
> https://cabforum.org/pipermail/public/2014-September/003921.html ), 
> but none really nailed it down to the level you have.
> 
> Broadly, it suggests the need for a much tighter profile of OCSP, 
> either within policies or the BRs. Two years ago, I started work on 
> such a thing -
> https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large 
> CA suggested it would take them years to even implement that, and it 
> wouldn't have covered this!
> 
> I can't see #3 being valid, but I can see and understand good 
> arguments for
> #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960.
> 
> The question about whether #2 is valid is about whether or not a 
> client should be expected to be able to match the CertID in the 
> OCSPRequest.requestList to the CertID in the 
> OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that 
> the response MUST include a SingleResponse for each certificate in the 
> request, but may include additional, and so a client encountering a 
> SHA-1 computed CertID in response to a SHA-256 CertID would have to 
> recompute all the CertIDs to see if it matched. On the other hand, RFC 
> 5019 2.2.1 states that "In the case where a responder does not have 
> the ability to respond to an OCSP response containing an option not 
> supported by the server, it SHOULD return the most complete response it can."
> 
> A different question would be whether said responder, in response to a
> SHA-1 request, can and/or should provide a response with both a SHA-1 
> computed CertID AND a SHA-256 computed CertID. This would improve the 
> pre-generation performance that Rob was concerned about, and allow 
> both
> SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse.
> 
> However, one concern with the pre-generation approach is that 4.2.2.3 
> requires that the response MUST include a SingleResponse for each 
> certificate in the request. RFC 5019 2.1.1 limits clients using that 
> profile to only include one Request in the OCSPRequest.RequestList 
> (via a MUST). So should responders be permitted to reject requests 
> that include multiple? Or should they be required to do online 
> signing? Similar to extensions.
> 
> This suggests we should actually nail down and define what we expect, 
> perhaps as a clear processing algorithm for how a Responder must 
> respond to various requests. I suspect that "What we want" is a 
> profile of RFC 5019 that nails down the SHOULD / SHOULD NOT and MAY /

RE: OCSP responder support for SHA256 issuer identifier info

[Jeremy Rowley via dev-security-policy]

(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 12:35 PM
To: Tomas Gustavsson ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: 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 algorithm for the CertID.issuerNameHash 
and the CertID.issuerKeyHash values. Anyone implementing the BRs would expect 
SHA1 for both fields. Where does the requirement to support SHA256 come in? As 
Ryan mentioned, there was some discussion, but it seems like there was nothing 
settled. I'd support a ballot clarifying the profile, but I don't understand 
the value of requiring both SHA1 and SHA2 signatures for OCSP. Doesn't it just 
make OCSP more cumbersome? 

-Original Message-
From: dev-security-policy  On 
Behalf Of Tomas Gustavsson via dev-security-policy
Sent: Friday, October 4, 2019 1:45 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: OCSP responder support for SHA256 issuer identifier info

I was pointed to this interesting discussion. We were forced to support 
requests with SHA256 in CertID back in 2014. Not for any relevant security 
reasons, just because some stubborn auditors saw a red flag on the mentioning 
of SHA-1.

We've implemented it by having both hashes in the lookup table where we check 
for issuer when a response comes in. 

What to have in the response was an interesting topic.

In the response we use the same certID that the client sent. I would expect 
that any client if checking CertID in the response would expect it to match 
what they send. 

I'm suspicious of adding two SingleResponse in the response, one for each 
CertID. 
- Clients are used to one response, they may fail verification if the first one 
doesn't have the same CertID
- When auditors that requiring SHA3, shall we add three? That approach does not 
seem agile.
- It increases the size of responses, we've been told before about the desire 
to keep responses as small as possible (typically to fit in a single etehrnet 
frame)

Regards,
Tomas

On Thursday, September 19, 2019 at 7:45:10 PM UTC+2, Ryan Sleevi wrote:
> Thanks for raising this!
> 
> There some some slight past discussion in the CA/B Forum on this - 
> https://cabforum.org/pipermail/public/2013-November/002440.html - as 
> well as a little during the SHA-1 deprecation discussions ( 
> https://cabforum.org/pipermail/public/2016-November/008979.html ) and 
> crypto agility discussions ( 
> https://cabforum.org/pipermail/public/2014-September/003921.html ), 
> but none really nailed it down to the level you have.
> 
> Broadly, it suggests the need for a much tighter profile of OCSP, 
> either within policies or the BRs. Two years ago, I started work on 
> such a thing -
> https://github.com/sleevi/cabforum-docs/pull/2 - but a certain large 
> CA suggested it would take them years to even implement that, and it 
> wouldn't have covered this!
> 
> I can't see #3 being valid, but I can see and understand good 
> arguments for
> #1 and #4. I don't think #5 works, because of Section 2.3 of RFC 6960.
> 
> The question about whether #2 is valid is about whether or not a 
> client should be expected to be able to match the CertID in the 
> OCSPRequest.requestList to the CertID in the 
> OCSPResponse.BasicOCSPResponse.responses list. 4.2.2.3 requires that 
> the response MUST include a SingleResponse for each certificate in the 
> request, but may include additional, and so a client encountering a
> SHA-1 computed CertID in response to a SHA-256 CertID would have to 
> recompute all the CertIDs to see if it matched. On the other hand, RFC
> 5019 2.2.1 states that "In the case where a responder does not have 
> the ability to respond to an OCSP response containing an option not 
> supported by the server, it SHOULD return the most complete response it can."
> 
> A different question would be whether said responder, in response to a
> SHA-1 request, can and/or should provide a response with both a SHA-1 
> computed CertID AND a SHA-256 computed CertID. This would improve the 
> pre-generation performance that Rob was concerned about, and allow 
> both
> SHA-1 and SHA-2 requests to be satisfied by the same BasicOCSPResponse.
> 
> However, one concern with the pre-generation approach is that 4.2.2.3 
> requires that the res

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

[Jeremy Rowley via dev-security-policy]

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 they do need to issue 
certificates for a few email addresses outside of their domain control. 
Verification of email control using a random value seems like it affords 
controls that are equivalent to the challenge-response mechanisms in the BRs.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, October 4, 2019 2:38 PM
To: Kathleen Wilson 
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

I'd like to revive this discussion. So far we've established that the existing 
"required practice" [1] is too stringent for email address validation and needs 
to be changed. We can do that by removing email addresses from the scope of the 
requirement as Kathleen proposed, or by exempting the local part of the email 
address as I proposed earlier:

"CAs MUST NOT delegate validation of the domain name part of an email address 
to a 3rd party."

We have a fairly detailed explanation from Ryan Hurst of why and how removing 
the requirement entirely is beneficial, but no one else has spoken in favor of 
this need. Kathleen did however point out that this requirement doesn't appear 
to be the result of a thorough analysis. We have Ryan Sleevi arguing that the 
process described by Ryan Hurst is insecure and thus a reason to forbid 
delegation of validation of the domain name part. Pedro Fuentes also wrote in 
favor of this outcome.

One thing that might help to resolve this is a more detailed description of the 
weaknesses that are present in the process described by Ryan Hurst. If we can 
all agree that the process is vulnerable, then it seems that we'd have a strong 
argument for banning it.

- Wayne

[1]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties


On Thu, May 23, 2019 at 12:22 PM Kathleen Wilson via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On 5/13/19 10:24 AM, Wayne Thayer wrote:
> > The BRs forbid delegation of domain and IP address validation to 
> > third parties. However, the BRs don't forbid delegation of email 
> > address validation nor do they apply to S/MIME certificates.
> >
> > Delegation of email address validation is already addressed by 
> > Mozilla's Forbidden Practices [1] state:
> >
> > "Domain and Email validation are core requirements of the Mozilla's 
> > Root Store Policy and should always be incorporated into the issuing 
> > CA's procedures. Delegating this function to 3rd parties is not permitted."
> >
> > I propose that we move this statement (changing "the Mozilla's Root 
> > Store Policy" to "this policy") into policy section 2.2 "Validation 
> > Practices".
> >
> > This is https://github.com/mozilla/pkipolicy/issues/175
> >
> > I will appreciate everyone's input on this proposal.
> >
> > - Wayne
> >
> > [1]
> >
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegat
> ion_of_Domain_.2F_Email_Validation_to_Third_Parties
> >
>
>
> All,
>
> As the person who filed the Github issue for this, I would like to 
> provide some background and my opinion.
>
> Currently the 'Delegation of Domain / Email Validation to Third Parties'
> section of the 'Forbidden Practices' page says:
> "This is forbidden by the Baseline Requirements, section 1.3.2.
> Domain and Email validation are core requirements of the Mozilla's 
> Root Store Policy and should always be incorporated into the issuing 
> CA's procedures. Delegating this function to 3rd parties is not permitted."
>
> Based on the way that section is written, it appears that domain 
> validation (and the BRs) was the primary consideration, and that the 
> Email part of it was an afterthought, or added later. Historically, my 
> attention has been focused on TLS certs, so it is possible that the 
> ramifications of adding Email validation to this section was not fully 
> thought through.
>
> I don't remember who added this email validation text or when, but I 
> can tell you that when I review root inclusion requests I have only 
> been concerned about making sure that domain validation is not being 
> delegated to 3rd parties. It wasn't until a representative of a CA 
> brought this to my attention that I realized that there has been a 
> difference in text on this wiki page versus the rules I have been 
> trying to enforce. That is when I filed the github issue.
>
> I propose that we can resolve this discrepancy for now by removing "/ 
> Email Validation" from the title of the section and removing "and Email"
> from the contents of the section.
>
> Unless we believe there are significant sec

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

[Jeremy Rowley via dev-security-policy]

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 2020 as the non-browser TLS. We aren’t expanding the sub CAs 
beyond what exists while we figure out what to do with existing infrastructures 
that are using them.

That said, still wearing a personal hat, I do think the community should have 
access to this information and review the entities that transitively chain up 
to the Mozilla root program for sMIME or TLS. There should be a review of all 
these sub CAs, including the Trust Italia one we replaced. The only reason I 
can see grandfathering is if there are too many to review at one time. Then 
grandfather the new ones and review before a new CA is required to issue. 
That’ll spur CAs to bring the on-prem Sub CAs forward for review.

The bigger question to me, is how should this review take place? Should the 
root CA sponsor the sub CA and talk about the infrastructure and operations? I 
think there should be an established process of how this occurs, and the 
process is probably slightly different than roots because of the extra party 
(root CA) involved.

From: Wayne Thayer 
Sent: Friday, October 4, 2019 12:40 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Thanks Jeremy.

On Thu, Oct 3, 2019 at 5:06 PM Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:
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 Subordinate CA Owner 
field. Section 8 links to emailing 
certifica...@mozilla.org but operationally, 
CCADB has become the default means of providing this notice. If you're 
expecting email, that may be worth clarifying in case CAs missed that an email 
is required. I know I missed that, and because CCADB is the common method of 
notification there is a chance that notice was considered sent but not in the 
expected way.

Considering that section 8 links to an email address where it states "MUST 
notify Mozilla", I'm skeptical that there is 
confusion, but I do agree that it makes sense for the notification to be 
triggered via an update to CCADB rather than an email. I'll look in to this.

There's also confusion over the "new to Mozilla" language I think. I 
interpreted this language as organizations issued cross-signs after the policy. 
For example, Siemens operated a Sub CA through Quovadis prior to policy date so 
they aren't "new" to the CA space even if they were re-certified.

That's the correct interpretation, barring any further clarifications...

However, they would be new in the sense you identified - they haven't gone 
through an extensive review by the community.  If the goal is to ensure the 
community review happens for each Sub CA, then requiring all recertifications 
to go through an approval process makes sense instead of making an exception 
for new. I'm not sure how many exist currently, but if there are not that many 
organizations, does a grandfathering clause cause unnecessary complexity? I 
realize this is not in DigiCert's best interest, but the community may benefit 
the most by simply requiring a review of all Sub CAs instead of trying to 
grandfather in existing cross-signs.  Do you have an idea on the number that 
might entail? At worst, we waste a bunch of time discovering that all of these 
are perfectly operated and that they could have been grandfathered in the first 
place. At best, we identify some critical issues and resolve them as a 
community.

It appears to be at least 2 dozen organizations, based on the "subordinate CA 
owner" field in CCADB. I say "at least" because, as Dimitris noted, we're just 
now identifying intermediates that are incorrectly labeled as falling under the 
parent certificate's audits.

If there are a significant number of unconstrained on-prem CAs, then language 
that requires a review on re-signing would be helpful.  Perhaps say "As of X 
date, a CA MUST NOT sign a non-technically constrained certificate where 
cA=True for keys that are hosted external to the CA's infrastructure or that 
are not operated in accordance with the issuing CA's policies and procedures 
unless Mozilla has first granted permission for such certificate"? The wording 
needs work of course, but the idea is that they go through the discussion and 
Mozilla signs off. A process for unconstrained Sub CAs that is substantially 
similar to the root inclusion makes sense, but there is documentation on CCADB 
for the existing ones

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

[Jeremy Rowley via dev-security-policy]

I’m thinking more in terms of the potential rule in the Mozilla policy. If the 
rule is “the CA MUST verify the domain component of the email address” then the 
rule potentially prohibits the scenario where the CA verifies the entire email 
address, not the domain component, by sending a random value to each email 
address and requiring the email address holder to approve issuance. I actually 
liked the previous requirement prohibiting delegation of email address 
verification, although the rule lacked clarity on what email address 
verification entailed. I figure that will be defined in the s/MIME working 
group.

Describing the actors is a good way to look at it though. Besides those three 
buckets of issuers, you have the RAs, the email holders, and the organization 
controlling the domain portion of the email address. These entities may not be 
the same as the CA. More often than not, the RA ends up being the organization 
contracting with the CA for the s/MIME services. The RAs are the risky party 
that I think should be restricted on what they can verify since that’s where 
the lack of transparency starts to come in. With the prohibition against 
delegation of email control eliminated, we’re again placing domain/email 
control responsibilities on a party that has some incentive to misuse it (to 
read email of a third party) without audit, technical, or policy controls that 
limit their authority.  Because there are a lack of controls over the RAs, they 
become a hidden layer in the process that can issue certificates without anyone 
looking at how they are verifying the email address or domain name and whether 
these processes are equivalent to the controls found int eh BR.  Similar to 
TLS, the unaudited party should not be the one providing or verifying 
acceptance of the tokens used to approve issuance.

In short, I’m agreeing with the “at least” verifying the domain control 
portion. However, I know we verify a lot of email addresses directly with the 
email owner that doesn’t have control over the domain name. So the rule should 
be something that permits verification by the root CA of either the full email 
address or the domain name but at least eliminates delegation to non-audited 
third parties. For phrasing, “the CA MUST verify either the domain component of 
the email address or the entire email address using a process that is 
substantially similar to the process used to verify domain names as described 
in the Baseline Requirements”, with the understanding that we will rip out the 
language and replace it with the s/MIME requirements once those are complete at 
the CAB Forum.

Jeremy

From: Ryan Sleevi 
Sent: Friday, October 4, 2019 10:56 PM
To: Jeremy Rowley 
Cc: Kathleen Wilson ; Wayne Thayer ; 
mozilla-dev-security-policy 
Subject: Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for 
S/MIME Certificates

Jeremy:

Could you describe a bit more who the actors are?

Basically, it seems that the actual issuance is going to fall into one of 
several buckets:
1) Root CA controls Issuing CAs key
2) Issuing CA controls its own key, but is technically constrained
3) Issuing CA controls its own key, and is not technically constrained

We know #1 is covered by Root CA’s audit, and we know #3 is covered by Issuing 
CA’s audit, and #2 is technically constrained and thus the domain part is 
apriori validated.

So when you say “some organizations”, I’m trying to understand which of the 
three cases here they fall under. If I understand correctly, the idea is that 
Customer Foo approaches Root CA (Case #1). Root CA knows Foo’s namespace is 
foo.example through prior verification, and Root CA allows Foo to issue to 
*@foo.example<mailto:*@foo.example>. Then Foo says “oh, hey, we have a 
contractor at user@bar.example<mailto:user@bar.example>, we’d like a cert for 
them too”.

Why can’t Root CA verify themselves? Why would or should Root CA trust Foo to 
do it correctly? I can imagine plenty of verification protocols where Foo can 
be the “face” of the verification, but that it uses Root CAs APIs and systems 
under the hood. I‘m fairly certain DigiCert has experience doing this for their 
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.org>>
 wrote:
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 they do need to issue 
certificates for a few email addresses outside of their domain control. 
Verification of email control using a random value seems like it affords 
controls that are equi

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

[Jeremy Rowley via dev-security-policy]

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 on the root.

That said, I don't personally see the harm in incident reports (other than the 
fact that they can be used for negative marketing). They are there for 
documenting issues and making the public aware of issues. Like qualified 
audits, they don't necessarily mean something terrible since they represent a 
disclosure/record of some kind. Even if the incident report is open, discussed, 
and closed pretty quickly, then you end up with an a record that can be pointed 
to.  Filing more incident report (as long as they are different issues) is a 
good thing as it gives extra transparency in the CA's operations that is easily 
discoverable and catalogable. Makes data analytics easier and you can go back 
through the incidents to see how things are changing with the CA.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 9:35 AM
To: Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Mon, Oct 7, 2019 at 11:26 AM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On 07/10/2019 16:52, Ryan Sleevi wrote:
> > I'm curious how folks feel about the following practice:
> >
> > Imagine a CA, "Foo", that creates a new Root Certificate ("Root 1"). 
> > They create this Root Certificate after the effective date of the 
> > Baseline Requirements, but prior to Root Programs consistently 
> > requiring
> compliance
> > with the Baseline Requirements (i.e. between 2012 and 2014). This 
> > Root Certificate does not comply with the BRs' rules on Subject: 
> > namely, it omits the Country field.
>
> Clarification needed: Does it omit Country from the DN of the root 1 
> itself, from the DN of intermediary CA certs and/or from the DN of End 
> Entity certs?
>

It's as I stated: The Subject of the Root Certificate omits the Country field.


> >
> > Later, in 2019, Foo takes their existing Root Certificate ("Root 
> > 2"), included within Mozilla products, and cross-signs the Subject. 
> > This now creates a cross-signed certificate, "Root 1 signed-by Root 
> > 2", which has
> a
> > Subject field that does not comport with the Baseline Requirements.
>
> Nit: Signs the Subject => Signs Root 1
>

Perhaps it would be helpful if you were clearer about what you believe you were 
correcting.

I thought I was very precise here, so it's useful to understand your
confusion:

Root 2, a root included in Mozilla products, cross-signs Root 1, a root which 
omits the Country field from the Subject.

This creates a certificate, whose issuer is Root 2 (a Root included in Mozilla 
Products), and whose Subject is Root 1. The Subject of Root 1 does not meet the 
BRs requirements on Subjects for intermediate/root
certificates: namely, the certificate issued by Root 2 omits the C, because 
Root 1 omits the C.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 acknowledge this is somewhat a non-answer, but I think if the CA 
discloses why they are signing something, works with the community to decide 
the action taken is better than the alternative, accepts the risk to the audit, 
then they should do it, assuming the risk. The BRs are pretty rigid so there 
may be circumstances that merit violation of the requirements, but that 
violation should only be done with as much transparency as possible and 
considering all the positions. 

For example, suppose a root was created before a rule went into place and the 
root needs to be renewed for some reason. If the root was compliant before 
creation and modifying the profile would break something with the root, then 
there's a good argument that you shouldn't modify the root during the resign. 
That assumes the reasons are discussed here and alternatives are explored 
fully.  This should then be documented (including the reasons) in an incident 
report and the subsequent audit. 

Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. But I 
could see there being reasons for the CA to do so.

(And I haven't scanned CT to discover if it is us. Crossing my fingers it's not 
😊. If I don't scan, it's like a terrible version of Christmas.)

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 10:07 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley 
wrote:

> 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 on the root.
>

Good question!

Yes, it turns out that a version of this cross-sign is included, and while 
there was a public discussion phase, this non-compliance was not detected 
during the inclusion request nor part of the discussion. In fact, there were 
zero comments during the public discussion phase.


> That said, I don't personally see the harm in incident reports (other 
> than the fact that they can be used for negative marketing). They are 
> there for documenting issues and making the public aware of issues. 
> Like qualified audits, they don't necessarily mean something terrible 
> since they represent a disclosure/record of some kind. Even if the 
> incident report is open, discussed, and closed pretty quickly, then 
> you end up with an a record that can be pointed to.  Filing more 
> incident report (as long as they are different issues) is a good thing 
> as it gives extra transparency in the CA's operations that is easily 
> discoverable and catalogable. Makes data analytics easier and you can 
> go back through the incidents to see how things are changing with the CA.
>

Well, the reason I raised it here, rather than as an incident, was to try and 
nail down the expectations here. For example, would it be better to have that 
discussion on the incident, with "Foo" arguing "You approved it, ergo it's not 
a violation to cross-sign it"? Or would it be better to have visibility here, 
perhaps in the abstract (even if it is trivial to scan CT and figure out which 
CA I'm talking about), if only to get folks expectations here on whether or not 
new certificates should be signed that violate the BRs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

For this particular incident, I would like to know why the CA didn’t review the 
profile before signing the root. It seems like a flaw in the process in the key 
ceremony process not to go through a checklist with the profile and ensure each 
field complies with the current version of BRs. 

Question on browser behavior - will revocation of the cross essentially result 
in revocation of root 2 since the date is newer? Anyone distributing that 
cross, will basically see the root as revoked unless they have the root 
embedded by then, right?

-Original Message-
From: dev-security-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 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 acknowledge this is somewhat a non-answer, but I think if the CA 
discloses why they are signing something, works with the community to decide 
the action taken is better than the alternative, accepts the risk to the audit, 
then they should do it, assuming the risk. The BRs are pretty rigid so there 
may be circumstances that merit violation of the requirements, but that 
violation should only be done with as much transparency as possible and 
considering all the positions. 

For example, suppose a root was created before a rule went into place and the 
root needs to be renewed for some reason. If the root was compliant before 
creation and modifying the profile would break something with the root, then 
there's a good argument that you shouldn't modify the root during the resign. 
That assumes the reasons are discussed here and alternatives are explored 
fully.  This should then be documented (including the reasons) in an incident 
report and the subsequent audit. 

Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. But I 
could see there being reasons for the CA to do so.

(And I haven't scanned CT to discover if it is us. Crossing my fingers it's not 
😊. If I don't scan, it's like a terrible version of Christmas.)

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 10:07 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley 
wrote:

> 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 on the root.
>

Good question!

Yes, it turns out that a version of this cross-sign is included, and while 
there was a public discussion phase, this non-compliance was not detected 
during the inclusion request nor part of the discussion. In fact, there were 
zero comments during the public discussion phase.


> That said, I don't personally see the harm in incident reports (other 
> than the fact that they can be used for negative marketing). They are 
> there for documenting issues and making the public aware of issues.
> Like qualified audits, they don't necessarily mean something terrible 
> since they represent a disclosure/record of some kind. Even if the 
> incident report is open, discussed, and closed pretty quickly, then 
> you end up with an a record that can be pointed to.  Filing more 
> incident report (as long as they are different issues) is a good thing 
> as it gives extra transparency in the CA's operations that is easily 
> discoverable and catalogable. Makes data analytics easier and you can 
> go back through the incidents to see how things are changing with the CA.
>

Well, the reason I raised it here, rather than as an incident, was to try and 
nail down the expectations here. For example, would it be better to have that 
discussion on the incident, with "Foo" arguing "You approved it, ergo it's not 
a violation to cross-sign it"? Or would it be better to have visibility here, 
perhaps in the abstract (even if it is trivial to scan CT and figure out which 
CA I'm talking about), if only to get folks expectations here on whether or not 
new certificates should be signed that violate the BRs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___

RE: Mozilla Policy Requirements CA Incidents

[Jeremy Rowley via dev-security-policy]

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 identical (source?), 
but we know some CAs treat these as different instances.  While that's not an 
excuse, I can see why a CA could have issues with a renewal compared to new 
issuance as changing the profile may break the underlying CA.

Note that revoking these CAs puts the CA back on issuing from the legacy ICA 
that was issued before the renewal. Depending on the reason for the reissue, 
that may be a less desirable outcome.  I don't have a good answer on what to do 
in a circumstance like this (and I'm a bit biased probably since we have a 
relationship with Quovadis).  However, there's probably something better than 
"trust" vs. "distrust" or "revoke" v "non-revoke", especially when it comes to 
an intermediate.  I guess the question is what is the primary goal for Mozilla? 
Protect users? Enforce compliance?  They are not mutually exclusive objectives 
of course, but the primary drive may influence how to treat issuing CA 
non-compliance vs. end-entity compliance. 

Of the four, only Quovadis has responded to the incident with real information, 
and none of them have filed the required format or given sufficient 
information. Is it too early to say what happens before there is more 
information about what went wrong? Key ceremonies are, unfortunately, very 
manual beasts. You can automate a lot of it with scripting tools, but the 
process of taking a key out, performing a ceremony, and putting things a way is 
not automated due to the off-line root and FIPS 140-3 requirements. 

BTW, I'm really liking how these issues are raised here in bulk by problem. 
This is a really nice format and gets the community involved in looking at what 
to do.  I think it also helps identify common causes of problems.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 12:53 PM
To: mozilla-dev-security-policy 
Subject: Mozilla Policy Requirements CA Incidents

In light of Wayne's many planned updates as part of version 2.7 of the Mozilla 
Root Store Policy, and prompted by some folks looking at adding linters, I 
recently went through and spot-checked some of the Mozilla Policy-specific 
requirements to see how well CAs are doing at following these.

I discovered five issues, below:

# Intermediates that do not comply with the EKU requirements

In September 2018 [1], Mozilla sent a CA Communications reminding CAs about the 
changes in Policy 2.6.1. One specific change, called to attention in ACTION 3, 
required the presence of EKUs for intermediates, and the separation of e-mail 
and SSL/TLS from the intermediates. This requirement, while new to Mozilla 
Policy, was not new to publicly trusted CAs, as it matched an existing 
requirement from Microsoft's Root Program [2]. This requirement was first 
introduced by Microsoft in July 2015, with their Version 2.0 of their own 
policy.

It's a reasonable expectation to expect that all CAs in both Microsoft and 
Mozilla's program would have been conforming to the stricter requirement of 
Microsoft, which goes above-and-beyond the Baseline Requirements. However, 
Mozilla still allowed a grandfathering in of existing intermediates, setting 
the new requirement for their policy at 2019-01-01. Mozilla also set forth 
certain exclusions to account for cross-signing.

Despite that, four CAs have violated this requirement in 2019:
* Microsoft: https://bugzilla.mozilla.org/show_bug.cgi?id=1586847
* Actalis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586787
* QuoVadis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586792
* NetLock: https://bugzilla.mozilla.org/show_bug.cgi?id=1586795

# Authority Key Identifier issues

RFC 5280, Section 4.2.1.1 [3], defines the Authority Key Identifier extension. 
Within RFC 5280, it states that (emphasis added)

   The identification MAY be based on ***either*** the
   key identifier (the subject key identifier in the issuer's
   certificate) ***or*** the issuer name and serial number.

That is, it provides an either/or requirement for this field. Despite this not 
being captured in the updated ASN.1 module defined in RFC 5912 [4], Mozilla 
Root Store Policy has, since Version 1.0 [5], included a requirement that CAs 
MUST NOT issue certificates that have (emphasis added) "incorrect extensions 
(e.g., SSL certificates that exclude SSL usage, or ***authority key IDs that 
include both the key ID and the issuer's issuer name and serial number)***;"

In examining issuance, I found that one CA, trusted by Mozilla, regularly 
violates this requirement:

* Camerfirma: https://bugzilla.mozilla.org/show_bug.cgi?id=1586860

# Thoughts

While I've opened CA incident issues for all

RE: Mozilla Policy Requirements CA Incidents

[Jeremy Rowley via dev-security-policy]

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 boxes. I also get the frustration with certain 
issues, especially when the pop up among CAs – especially if the rule is well 
established.

I’ve been looking at the root causes of mis-issuance in detail (stating with 
DigiCert) and so far I’ve found they divide into a few buckets. 1) Where the CA 
relied on a third party for something and probably shouldn’t have, 2) where 
there was an internal engineering issue, 3) a manual process went bad, 4) 
software the CA relied on had an issue, or 5) the CA simply couldn’t/didn’t act 
in time. From the incidents I’ve categorized so far (still working on all the 
incidents for all CAs), the biggest buckets seem like engineering issues 
followed by manual process issues. For example, at DigiCert proper the 
engineering issues represent about 35% of the issues. (By DigiCert proper, I 
exclude the Sub CAs and Quovadis systems – this allows me to look exclusively 
at our internal operations compared to the operations of somewhat separate 
systems.)  The next biggest issue is our failure to move fast enough (30%) 
followed by manual process problems (24%). DigiCert proper doesn’t use very 
much third party software in its CA so that tends to be our smallest bucket.

The division between these categories is interesting because some are less in 
control of the CA than others. For example, if primekey has an issue pretty 
much everyone has an issue since so many CAs use primekey at some level 
(DigiCert via Quovadis). The division is also somewhat arbitrary and based 
solely on the filed incident reports. However, what I’m looking for is whether 
the issues result from human error, insufficient implementation timelines, 
engineering issues, or software issues.  I’m not ready to make a conclusion 
industry-wide.

The trend I’ve noticed at DigiCert is the percent of issues related to DigiCert 
manual processes is decreasing while the percent of engineering blips is 
increasing. This is a good trend as it means we are moving away from manual 
processes and into better automation. What else is interesting is the number of 
times we’ve had issues with moving too slow has dropped significantly over the 
last two year, which means we’ve seen substantial improvement in communication 
and handling of changes in industry standards. The number of issues increased, 
but I chalk that up to more transparency and scrutiny by the public (a good 
thing) than worse systems.

The net result is a nice report that we’re using internally (and will share 
externally) that shows where the biggest improvements have been made. We’re 
also hoping this data shows where we need to concentrate more. Right now, the 
data is showing more focus on engineering and unit tests to ensure all systems 
are updated when a guideline changes.

So why do I share this data now before it’s ready?  Well, I think looking at 
this information can maybe help define possible solutions. Long and windy, but…

One resulting idea is that maybe you could require a report on improvements 
from each CA based on their issues?  The annual audit could include a report 
similar to the above where the CA looks at the past year of their own mistakes 
and the other industry issues and evaluates how well they did compared to 
previous years. This report can also describe how the CA changed their system 
to comply with any new Mozilla or CAB Forum requirements. What automated 
process did they put in place to guarantee compliance? This part of the audit 
report can be used to reflect on the CA operations and make suggestions to the 
browsers on where they need to improve and where they need to automate. It can 
also be used to document one area of improvement they need to focus on.

Although this doesn’t cure immediate mis-issuances such does give better 
transparency into what CAs are doing to improve and exactly how they 
implemented the changes made to the Mozilla policy. A report like this also 
shifts the burden of dealing with issues to the community instead of the module 
owners and emphasizes the CA on fixing their systems and learning from 
mistakes. With the change to WebTrust audits, there’s an opportunity for more 
free-form reporting that can include this information. And this information has 
to be fare more interesting than reading about yet another individual who 
forgot to check a box in CCADB.

This is still more reactive than I’d like and sometimes requires a whole year 
before a CA gives information about the changes made to systems to reflect 
changes in policy. The report does get people thinking proactively about what 
they need to do to improve, which may, by itself, be a force for improvement. 
This also allows the community 

RE: Mozilla Policy Requirements CA Incidents

[Jeremy Rowley via dev-security-policy]

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 intensive procedure, 
there is lots that can go wrong  compared to end-entity certs, including bad 
profiles and bad coding. These events are also things that happen rarely enough 
that many CAs might not have well defined processes around. A couple things 
we’ve done to eliminate issues include:


  1.  2 person review over the profile + a formal sign-off from the policy 
authority
  2.  A standard scripting tool for generating the profile to ensure only the 
subject info in the cert changes.  This has basic some linting.
  3.  We issue a demo cert. This cert is exactly the same as the cert we want 
to issue but it’s not publicly trusted and includes a different serial. We then 
review the demo cert to ensure profile accuracy. We should run this cert 
through a linter (added to my to-do list).

We used to treat renewals separate from new issuance. I think there’s still a 
sense that they “are” different, but that’s been changing. I’m definitely 
looking forward to hearing what other CAs do.

Jeremy


From: Wayne Thayer 
Sent: Tuesday, October 8, 2019 3:20 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: Mozilla Policy Requirements CA Incidents

Ryan,

Thank you for pointing out these incidents, and for raising the meta-issue of 
policy compliance. We saw similar issues with CP/CPS compliance to changes in 
the 2.5 and 2.6 versions of policy, with little explanation beyond "it's hard 
to update our CPS" and "oops". Historically, our approach has been to strive to 
communicate policy updates to CAs with the assumption that they will happily 
comply with all of the requirements they are aware of. I don't think that's a 
bad thing to continue, but I agree it is is not working.

Having said that, I do recognize that translating "Intermediates must contain 
EKUs" into "don't renew this particular certificate" across an organization 
isn't as easy as it sounds. I'd be really interested in hearing how CAs are 
successfully managing the task of adapting to new requirements and if there is 
something we can do to encourage all CAs to adopt best practices in this 
regard. Our reactive options short of outright distrust are limited- so I think 
it would be worthwhile to focus on new preventive measures.

Thanks,

Wayne

On Tue, Oct 8, 2019 at 11:02 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
On the topic of root causes, there's also
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3425554 that was
recently published. I'm not sure if that was peer reviewed, but it does
provide an analysis of m.d.s.p and Bugzilla. I have some concerns about the
study methodology (for example, when incident reports became normalized is
relevant, as well as incident reporting where security researchers first
went to the CA), but I think it looks at root causes a bit holistically.

I recently shared on the CA/B Forum's mailing list another example of
"routine" violation:
https://cabforum.org/pipermail/servercert-wg/2019-October/001154.html

My concern is that, 7 years later, while I think that compliance has
marginally improved (largely due to things led by outside the CA ecosystem,
like CT and ZLint/Certlint), I think the answers/responses/explanations we
get are still falling into the same predictable buckets, and that concerns
me, because it's neither sustainable nor healthy for the ecosystem.


   - We misinterpreted the requirements. It said X, but we thought it meant
   Y (Often: even though there's nothing in the text to support Y, that's just
   how we used to do business, and we're CAs so we know more than browsers
   about what browsers expect from us)
   - We weren't paying attention to the updates. We've now assigned people
   to follow updates.
   - We do X by saying our staff should do X. In this case, they forgot.
   We've retrained our staff / replaced our staff / added more staff to
   correct this.
   - We had a bug. We did not detect the bug because we did not have tests
   for this. We've added tests.
   - We weren't sure if X was wrong, but since no one complained, we
   assumed it was OK.
   - Our auditor said it was OK
   - Our vendor said it was OK

and so forth.

And then, in the responses, we generally see:

   - These certificates are used in Very Important Systems, so even though
   we said we'd comply, we cannot comply.
   - We don't think X is actually bad. We think X should be OK, and it
   should be Browsers that reject X if they don't like X (implicit: But they
   should still trust our CA, even though we aren't doing what they want)
   - Our vendor is not able to develop a fix in time, so we need more time.
   - We agree that X is

RE: Mozilla Policy Requirements CA Incidents

[Jeremy Rowley via dev-security-policy]

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 now. That was an oversight that we should 
fix. Publication of profiles probably won’t prevent issues related to 
engineering snafu’s or more manual procedures. However, publication may 
eliminate a lot of the disagreement on BR/Mozilla policy wording. That’s a lot 
more work though for the policy owners so the community would probably need to 
be more actively involved in reviewing profiles. Requiring publication at least 
gives the public a chance to review the information, which may not exist today.

The manual component definitely introduces a lot of risk in sub CA creation, 
and the explanation I gave is broader than renewals. It’s more about the risks 
currently associated with Sub CAs. The difference between renewal and new 
issuance doesn’t exist at DigiCert – we got caught on that issue a long time 
ago.


From: Ryan Sleevi 
Sent: Tuesday, October 8, 2019 5:49 PM
To: Jeremy Rowley 
Cc: Wayne Thayer ; Ryan Sleevi ; 
mozilla-dev-security-policy 
Subject: Re: Mozilla Policy Requirements CA Incidents



On Tue, Oct 8, 2019 at 6:42 PM Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:
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 intensive procedure, 
there is lots that can go wrong  compared to end-entity certs, including bad 
profiles and bad coding. These events are also things that happen rarely enough 
that many CAs might not have well defined processes around. A couple things 
we’ve done to eliminate issues include:


  1.  2 person review over the profile + a formal sign-off from the policy 
authority
  2.  A standard scripting tool for generating the profile to ensure only the 
subject info in the cert changes.  This has basic some linting.
  3.  We issue a demo cert. This cert is exactly the same as the cert we want 
to issue but it’s not publicly trusted and includes a different serial. We then 
review the demo cert to ensure profile accuracy. We should run this cert 
through a linter (added to my to-do list).

We used to treat renewals separate from new issuance. I think there’s still a 
sense that they “are” different, but that’s been changing. I’m definitely 
looking forward to hearing what other CAs do.

It's not clear: Are you suggesting the the configuration of sub-CA profiles is 
more, less, or the as risky as for end-entity certificates? It would seem that, 
regardless, the need for review and oversight is the same, so I'm not sure that 
#1 or #2 would be meaningfully different between the two types of certificates?

That said, of the incidents, only two of those were potentially related to the 
issuance of new versions of the intermediates (Actalis and QuoVadis). The other 
two were new issuance.

So I don't think we can explain it as entirely around renewals. I definitely 
appreciate the implicit point you're making: which is every manual action of a 
CA, or more generally, every action that requires a human be involved, is an 
opportunity for failure. It seems that we should replace all the humans, then, 
to mitigate the failure? ;)

To go back to your transparency suggestion, would we have been better if:
1) CAs were required to strictly disclose every single certificate profile for 
everything "they sign"
2) Demonstrate compliance by updating their CP/CPS to the new profile, by the 
deadline required. That is, requiring all CAs update their CP/CPS prior to 
2019-01-01.

Would this prevent issues? Maybe - only to extent CAs view their CP/CPS as 
authoritative, and strictly review what's on them. I worry that such a solution 
would lead to the "We published it, you didn't tell us it was bad" sort of 
situation (as we've seen with audit reports), which then further goes down a 
rabbit-hole of requiring CP/CPS be machine readable, and then tools to lint 
CP/CPS, etc. By the time we've added all of this complexity, I think it's 
reasonable to ask if the problem is not the humans in the loop, but the wrong 
humans (i.e. going back to distrusting the CA). I know that's jumping to 
conclusions, but it's part of what taking an earnest look at these issues are: 
how do we improve things, what are the costs, are there cheaper solutions that 
provide the same assurances?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DNS records and delegation

[Jeremy Rowley via dev-security-policy]

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 requires that the CA verify a domain by 
"confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record 
for either an Authorization Domain Name; or 2) an Authorization Domain Name 
that is prefixed with a label that begins with an underscore character."

If the CA is using a random value then the Random Value has to be unique the 
certificate request.

Could a third party or the CA itself set up a service of entities that hated 
doing domain validation? For example:



_validation.customer.com. 3600 IN CNAME _validation.domain.com.

_validation.domain.com. 3600 IN CNAME _validation.myvalidation.com.

_validation.myvalidation.com. 1 IN CNAME _.myalidation.com.

Since each domain approval request requires an unique random value, the random 
value could be uploaded each time a certificate request comes in and checked.

I mean, the obvious issue is the customer.com domain would need to want to 
delegate this domain.com. But if you had a pretty non-technical person 
operating the DNS, they could set it to the domain.com name and leave their DNS 
settings forever.

This looks allowed under the BRs, but should it be? Or is it like key escrow - 
okay if a reseller does it (but frowned upon). Totally not cool if the CA does 
it.

Jeremy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mozilla Policy Requirements CA Incidents

[Jeremy Rowley via dev-security-policy]

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 from the previous 
year. This could be helpful to document where an auditor changed between years 
to see what they reviewed that another auditor noted or to see where the 
auditor had concerns from year to year. It can track where the CA may have a 
re-occurring issue instead of something that is a one-off concern.

From: Ryan Sleevi 
Sent: Monday, October 14, 2019 4:12 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; Wayne Thayer 
; mozilla-dev-security-policy 

Subject: Re: Mozilla Policy Requirements CA Incidents

In the spirit of improving transparency, I've gone and filed 
https://github.com/mozilla/pkipolicy/issues/192 , which is specific to auditors.

However, I want to highlight this model (the model used by the US Federal PKI), 
because it may also provide a roadmap for dealing with issues like this / those 
called by policy changes. Appendix C of those annual requirements for the US 
Federal PKI includes a number of useful requirements (really, all of them are 
in line with things we've discussed here), but two particularly relevant 
requirements are:

Guidance: Previous year findings Did the auditor review findings from previous 
year and ensure all findings were corrected as proposed during the previous 
audit?
Commentary: Often, the auditor sees an Audit Correction Action Plan, POA&M, or 
other evidence that the organization has recognized audit findings and intends 
to correct them, but the auditor is not necessarily engaged to assess the 
corrections at the time they are applied. The auditor should review that all 
proposed corrections have addressed the previous year’s findings.

Guidance: Changes Because the FPKI relies on a mapped CP and/or CPS for 
comparable operations, has the auditor been apprised of changes both to 
documentation and operations from the previous audit?
Commentary: CPs change over time and each Participating PKI in the FPKI has an 
obligation to remain in synch with the changing requirements of the applicable 
FPKI CP (either FBCA or COMMON Policy) – has the participating PKI’s CP and CPS 
been updated appropriately? If there have been other major changes in 
operations, has a summary since the last year’s audit been provided or 
discussed with the auditor?


This might be a model to further include/require within the overall audit 
package. This would likely only make sense if also adding "Audit Operational 
Findings" (which Illustrative Guidance for WebTrust now includes guidance on, 
but which ETSI continues to refuse to add) and "Audit MOA Findings" (for which 
"MOA" may be instead seen as "Mozilla Root Certificate Policy" - i.e. the 
things above/beyond the BRs). We've already seen WebTrust similarly developing 
reporting for "Architectural Overview", and they've already updated reporting 
for "Assertion of Audit Scope", thus showing in many ways, WebTrust already has 
the tools available to meet these requirements. It would similarly be possible 
for ETSI-based audits to meet these requirements, since the reports provided to 
browsers need not be as limited as a Certification statement; they could 
include more holistic reporting, in line with the eIDAS Conformity Assessment 
Reports.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate OU= fields with missing O= field

[Jeremy Rowley via dev-security-policy]

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 to the O field 
information as long as the information is verified. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Alex Cohn via dev-security-policy
Sent: Friday, November 1, 2019 9:13 AM
To: Kurt Roeckx 
Cc: Matthias van de Meent ; MDSP 

Subject: Re: Certificate OU= fields with missing O= field

On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy 
 wrote:
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via 
> dev-security-policy wrote:
> > Hi,
> >
> > I recently noticed that a lot of leaf certificates [0] have 
> > organizationalUnitName specified without other organizational 
> > information such as organizationName. Many times this field is used 
> > for branding purposes, e.g. "issued through "
> > or "SomeBrand SSL".
> >
> > BR v1.6.6 § 7.1.4.2.2i has guidance on usage of the OU field: "The 
> > CA SHALL implement a process that prevents an OU attribute from 
> > including a name, DBA, tradename, trademark, address, location, or 
> > other text that refers to a specific natural person or Legal Entity 
> > unless the CA has verified this information in accordance with 
> > Section 3.2 and the Certificate also contains 
> > subject:organizationName, , subject:givenName, subject:surname, 
> > subject:localityName, and subject:countryName attributes, also 
> > verified in accordance with Section 3.2.2.1."
> >
> > As the organizationName and other related attributes are not set in 
> > many of those certificates, even though e.g. "COMODO SSL Unified 
> > Communications" is a very strong reference to Sectigo's ssl branding 
> > & business, I believe the referenced certificate is not issued in 
> > line with the BR.
> >
> > Is the above interpretation of BR section 7.1.4.2.2i correct?
>
> That OU clearly doesn't have anything to do with the subject that was 
> validated, so I also consider that a misissue.
>
>
> Kurt

A roughly-equivalent Censys.io query, excluding a couple other unambiguous 
"domain validated" OU values: "not _exists_:
parsed.subject.organization and _exists_:
parsed.subject.organizational_unit and not
parsed.subject.organizational_unit: "Domain Control Validated" and not
parsed.subject.organizational_unit: "Domain Validated Only" and not
parsed.subject.organizational_unit: "Domain Validated" and
validation.nss.valid: true" returns 17k hits.

IMO the "Hosted by .Com" certs fail 7.1.4.2.2i - the URL of a web host is 
definitely "text that refers to a specific ... Legal Entity".

> Certificate also contains subject:organizationName, , 
> subject:givenName, subject:surname, subject:localityName, and 
> subject:countryName attributes, also verified in accordance with Section 
> 3.2.2.1.

I'm pretty sure this isn't what the BRs intended, but this appears to forbid 
issuance with a meaningful subject:organizationalUnitName unless all of the 
above attributes are populated. EVG §9.2.9 forbids including those attributes 
in the first place. Am I reading this wrong, or was this an oversight in the 
BRs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificate OU= fields with missing O= field

[Jeremy Rowley via dev-security-policy]

My view is that the OU field is a subject distinguished name field and that a 
CA must have a process to prevent unverified information from being included in 
the field.

Subject Identity Information is defined as information that identifies the 
Certificate Subject.

I suppose the answer to your question depends on a) what you consider as 
information that identifies the Certificate Subject and b) whether the process 
required establishes the minimum relationship between that information and your 
definition of SII.

From: Ryan Sleevi 
Sent: Friday, November 1, 2019 10:11 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: Certificate OU= fields with missing O= field

Is your view that the OU is not Subject Identity Information, despite that 
being the Identity Information that appears in the Subject? Are there other 
fields and values that you believe are not SII? This seems inconsistent with 
7.1.4.2, the section in which this is placed.

As to the .com in the OU, 7.1.4.2 also prohibits this:
CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except 
as specified in Section 3.2.2.4 or Section 3.2.2.5.

On Fri, Nov 1, 2019 at 8:41 AM 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 fields. How would you ever have 
that?

There's no requirement that the OU field information relate to the O field 
information as long as the information is verified.

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Alex Cohn via dev-security-policy
Sent: Friday, November 1, 2019 9:13 AM
To: Kurt Roeckx mailto:k...@roeckx.be>>
Cc: Matthias van de Meent 
mailto:matthias.vandeme...@cofano.nl>>; MDSP 
mailto:dev-security-policy@lists.mozilla.org>>
Subject: Re: Certificate OU= fields with missing O= field

On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via 
> dev-security-policy wrote:
> > Hi,
> >
> > I recently noticed that a lot of leaf certificates [0] have
> > organizationalUnitName specified without other organizational
> > information such as organizationName. Many times this field is used
> > for branding purposes, e.g. "issued through "
> > or "SomeBrand SSL".
> >
> > BR v1.6.6 § 7.1.4.2.2i has guidance on usage of the OU field: "The
> > CA SHALL implement a process that prevents an OU attribute from
> > including a name, DBA, tradename, trademark, address, location, or
> > other text that refers to a specific natural person or Legal Entity
> > unless the CA has verified this information in accordance with
> > Section 3.2 and the Certificate also contains
> > subject:organizationName, , subject:givenName, subject:surname,
> > subject:localityName, and subject:countryName attributes, also
> > verified in accordance with Section 3.2.2.1."
> >
> > As the organizationName and other related attributes are not set in
> > many of those certificates, even though e.g. "COMODO SSL Unified
> > Communications" is a very strong reference to Sectigo's ssl branding
> > & business, I believe the referenced certificate is not issued in
> > line with the BR.
> >
> > Is the above interpretation of BR section 7.1.4.2.2i correct?
>
> That OU clearly doesn't have anything to do with the subject that was
> validated, so I also consider that a misissue.
>
>
> Kurt

A roughly-equivalent Censys.io query, excluding a couple other unambiguous 
"domain validated" OU values: "not _exists_:
parsed.subject.organization and _exists_:
parsed.subject.organizational_unit and not
parsed.subject.organizational_unit: "Domain Control Validated" and not
parsed.subject.organizational_unit: "Domain Validated Only" and not
parsed.subject.organizational_unit: "Domain Validated" and
validation.nss.valid: true" returns 17k hits.

IMO the "Hosted by .Com" certs fail 7.1.4.2.2i - the URL of a web host is 
definitely "text that refers to a specific ... Legal Entity".

> Certificate also contains subject:organizationName, ,
> subject:givenName, subject:surname, subject:localityName, and
> subject:countryName attributes, also verified in accordance with Section 
> 3.2.2.1.

I'm pretty sure this isn't what the BRs intended, but this appears to forbid 
issuance with a meaningful subject:organizationalUnitName un

RE: DRAFT January 2020 CA Communication

[Jeremy Rowley via dev-security-policy]

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, December 19, 2019 10:10 AM
To: mozilla-dev-security-policy 
Subject: DRAFT January 2020 CA Communication

All,

I've drafted a new email and survey that I plan to send to all CAs in the 
Mozilla program in early January. it focuses on compliance with the new
(2.7) version of our Root Store Policy. I will appreciate your review and 
feedback on the draft:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a051J3waNOW

Note that two deadlines have been added to the communication:
* Action 3 specifies that CAs must agree to update their CP/CPS, if needed to 
comply, prior to April 1, 2020. This is intended to prevent responses that we 
have found unacceptable in the past, e.g. waiting for an annual audit before 
updating the CP/CPS.
* Action 5 requires CAs with failed Intermediate ALV results to publish a plan 
to correct these problems no later than Feb 15, 2020. Kathleen announced that 
we have begun validating audit letters for intermediate certificates back in 
October [1], and the requirement for audit statements to contain the SHA256 
fingerprint of each root and intermediate certificate that was in scope of the 
audit dates back to 2017. CAs should have already taken action to resolve these 
issues, so this deadline is intended to convey the need for an immediate 
response.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/ZPDMRvDzBQAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Jeremy Rowley via dev-security-policy]

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 are 
generally used because so many companies haven't automated this process or 
refuse to. The companies who contribute to these threads tend to be far more 
technical than most other companies (or the majority of cert requesters). The 
assumption that each company has the resources to set up automation ignores 
this. The opposition to shorter lifecycles and validation periods stems from 
knowing these work flows and the painful exercise of changing them. 

The automated methods weren't even codified until ballot 169 which was late 
2016. We're at less than 4 years for automation being a real option. Although I 
don't have empirical data for other CAs, the LE adoption rate (a billion certs 
since indicates a fairly rapid adoption of automated methods compared to other 
changes in the industry. 

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 12, 2020 7:30 AM
To: Julien Cristau 
Cc: Mozilla ; Kathleen Wilson 

Subject: Re: About upcoming limits on trusted certificates

The Baseline Requirements allow a number of methods that aren’t easily 
automated, such as validation via email. As a result, CAs don’t pursue 
automation, or when they support it, neither promote nor require it. This leads 
CAs to be opposed to efforts to shorten the reuse time, as they have 
historically treated it as the same complexity as identity validation, even 
when it doesn’t need to be.

There’s nothing intrinsically preventing it, although the practical effect is 
it would encourage technically automatable methods, as opposed to manual 
methods.

On Thu, Mar 12, 2020 at 4:45 AM Julien Cristau via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Hi Kathleen, all,
>
> Is there a reason domain validation information needs to be reused for 
> more than, say, 30 days?  For the manual parts of identity validation 
> I understand you don't want to repeat the process too often, but 
> domain validation can be entirely automated so it doesn't seem like 
> long reuse periods are warranted. (It's entirely possible I'm missing 
> something and there are significant hurdles to overcome for CAs and/or 
> applicants in confirming domain ownership more than once a year.)
>
> Thanks,
> Julien
>
> On Wed, Mar 11, 2020 at 11:39 PM Kathleen Wilson via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
>
> > All,
> >
> > First, I would like to say that my preference would have been for 
> > this type of change (limit SSL cert validity period to 398 days) to 
> > be agreed to in the CA/Browser Forum and added to the BRs. However, 
> > the ball is already rolling, and discussion here in m.d.s.p is 
> > supportive of updating Mozilla's Root Store Policy to incorporate 
> > the shorter validity period. So...
> >
> > What do you all think about also limiting the re-use of domain
> validation?
> >
> > BR section 3.2.2.4 currently says: "Completed validations of 
> > Applicant authority may be valid for the issuance of multiple 
> > Certificates over time."
> > And BR section 4.2.1 currently says: "The CA MAY use the documents 
> > and data provided in Section 3.2 to verify certificate information, 
> > or may reuse previous validations themselves, provided that the CA 
> > obtained the data or document from a source specified under Section 
> > 3.2 or completed the validation itself no more than 825 days prior 
> > to issuing the Certificate."
> >
> > In line with that, section 2.1 of Mozilla's Root Store Policy 
> > currently
> > says:
> > "CAs whose certificates are included in Mozilla's root program MUST: ...
> > "5. verify that all of the information that is included in SSL 
> > certificates remains current and correct at time intervals of 825 
> > days or less;"
> >
> > When we update Mozilla's Root Store Policy, should we shorten the 
> > domain validation frequency to be in line with the shortened 
> > certificate validity period? i.e. change item 5 in section 2.1 of 
> > Mozilla's Root Store Policy to:
> > "5. limit the validity period and re-use of domain validation for 
> > SSL certificates to 398 days or less if the certificate is issued on 
> > or after September 1, 2020;"
> >
> > I realize that in order to enforce shorter frequency in domain 
> > validation we will need to get this change into the BRs and into the 
> > audit criteria. But CAs are expected to follow Mozilla's Root Store 
> > Policy regardless of enforcement mechanisms, and having this in our 
> > policy would make Mozilla's intentions clear.
> >
> > As always, I will greatly appreciate your thoughtful and 
> > constructive input on this.
> >
> > Thanks,
> > 

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

[Jeremy Rowley via dev-security-policy]

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 revoking upon 
termination also violates our internal policies - certs issued are good for the 
duration of the cert, even if the console agreement terminates.  

Since I'm sure we haven't actually revoked because of termination, please send 
me the details of the threats and I'll take care of them. 


-Original Message-
From: dev-security-policy  On 
Behalf Of Nick France via dev-security-policy
Sent: Tuesday, March 17, 2020 11:27 AM
To: Mozilla 
Subject: Re: Terms and Conditions that use technical measures to make it 
difficult to change CAs

On Monday, March 16, 2020 at 9:06:33 PM UTC, Tim Hollebeek wrote:
> Hello,
> 
>  
> 
> I'd like to start a discussion about some practices among other 
> commercial CAs that have recently come to my attention, which I 
> personally find disturbing.  While it's perfectly appropriate to have 
> Terms and Conditions associated with digital certificates, in some 
> circumstances, those Terms and Conditions seem explicitly designed to 
> prevent or hinder customers who wish to switch to a different 
> certificate authority.  Some of the most disturbing practices include 
> the revocation of existing certificates if a customer does not renew 
> an agreement, which can really hinder a smooth transition to a new 
> provider of digital certificates, especially since the customer may 
> not have anticipated the potential impact of such a clause when they 
> first signed the agreement.  I'm particularly concerned about this 
> behavior because it seems to be an abuse of the revocation system, and 
> imposes costs on everyone who is trying to generate accurate and efficient 
> lists of revoked certificates (e.g. Firefox).
> 
>  
> 
> I'm wondering what the Mozilla community thinks about such practices.
> 
>  
> 
> -Tim

Tim,

Completely agree on your statement that it's a disturbing practice. We've sadly 
come across it several times in the past 12-18 months, leading to problems for 
the customer and of course lost business for us as they inevitably decide to 
remain with the incumbent CA when faced with a hard deadline for certificate 
revocation - regardless of the natural expiry dates.
Your points about the impact and costs to the wider ecosystem ring true, as 
well.
Revocation should not be used to punish those wishing to migrate CAs. We 
certainly don't do it.

More troubling is that each time it's either been mentioned early in 
discussions or has caused a business discussion to cease at a late stage - it's 
been DigiCert that was the current CA and they/you participated in this 
practice of threatening revocation of certificates well before expiry due to 
contract termination.

I have at least 5 major global enterprises that this has happened to recently.

Am happy to share more details privately if you wish to discuss.


Nick
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: About upcoming limits on trusted certificates

[Jeremy Rowley via dev-security-policy]

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)? It's odd not to have 
the domain registration as the maximum cap on the range since that's when you 
know the domain is most at risk for transfer. 

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Tim Hollebeek via dev-security-policy
Sent: Tuesday, March 17, 2020 10:00 AM
To: Kathleen Wilson ; Mozilla 

Subject: RE: About upcoming limits on trusted certificates


> On 3/11/20 3:51 PM, Paul Walsh wrote:
> > Can you provide some insight to why you think a shorter frequency in
> domain validation would be beneficial?
>
> To start with, it is common for a domain name to be purchased for one year.
> A certificate owner that was able to prove ownership/control of the 
> domain name last year might not have renewed the domain name. So why 
> should they be able to get a renewal cert without having that re-checked?

This has been a favorite point of Jeremy's for as long as I've been 
participating in the CA/Browser Forum and on this list.  Tying certificate 
lifetimes more closely to the lifetime and validity of the domains they are 
protecting would actually make a lot of sense, and we'd support any efforts to 
do so.

-Tim
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 can't be 
revoked. Should that be mentioned, requiring CAs to file an incident report as 
soon as the event becomes likely? 

For the location issue, I think including the locations audited and the 
locations not audited (to the full criteria) as an emphasis of matter would be 
helpful. So maybe an emphasis like we audited the offices in x, y, and z. 
Office z was inaccessible to evaluate criteria 1-n. It give you the list of 
locations and where there were issues in getting access due t o he emergency. 
Same city is harder. For example, we have two locations in Utah. You could say 
Utah office 1 and Utah office 2 to obfuscate the information a little.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Kathleen Wilson via dev-security-policy
Sent: Friday, March 20, 2020 2:07 PM
To: Mozilla 
Subject: Re: Auditing of CA facilities in lockdown because of an environmental 
disaster/pandemic

All,

I will greatly appreciate your ideas about the following.

In the Minimum Expectations section in
https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
I added:
""
* Both ETSI and WebTrust Audits must:
** Disclose each location that was included in the scope of the audit, as well 
as whether the inspection was physically carried out in person.
""

My question: What should "location" mean in the above requirement?

The problem is that we require public-facing audit statements, so I do not want 
sensitive or confidential information in the audit statements, such as the 
exact physical addresses of CA Operations and root cert private key storage.

What information could be added to audit statements to give us a clear sense 
about which CA facilities were and were not audited?

For example, if a CA happens to have two facilities in the same city that 
should be audited, how can the audit statement clearly indicate if all of that 
CA's facilities were audited without providing the exact physical addresses?

Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 before the keys were blacklisted and 
not part of a certificate problem report.  When revoking a cert we scan to see 
if additional certs are issued with the same key t, but this particular cert 
one was issued after the scan but before the revocation, largely because the 
way you are submitting certificate problem reports breaks automation. We 
currently don't have a way to blacklist private keys until a certificate is 
revoked, although that would be a nice enhancement for us to add in the future. 
 Anyway, I don't think anything reported violated the  BR since 1) this cert 
was not part of a certificate problem report and 2) we will be revoking within 
24 hours of your Mozilla posting. 

I support the idea of swift revocation of compromised private keys and do 
appreciate you reporting them. I think this is helpful in ensuring the safety 
of users online. However, using the SPKI to submit information breaks our 
automation, making finding and revoking certs difficult. The more standards way 
(IMO) is the SHA2 thumbprint or serial number or a good old CSR.  Because 
submitting the SPKI breaks automation, getting evidence of key compromise took 
an additional 5 hours after you submitted the report. We still revoked all of 
the current certs with submitted keys within 24 hours of the report (since 
compromised private keys are bad and there is nothing that says we can't revoke 
earlier than 24 hours), but I did want to clarify that I don't think the time 
starts until we can actually get the information necessary to do an 
investigation (because there is not sufficient evidence of a key compromise 
until then). 

Going to the previous discussion, I'd definitely support seeing a standardized 
way to report key compromise. Trying to account for the various formats they 
come in and through the various channels creates a lot of manual work on a 
process that can easily be automated. 

Jeremy


-Original Message-
From: dev-security-policy  On 
Behalf Of Matt Palmer via dev-security-policy
Sent: Saturday, March 21, 2020 11:01 PM
To: Mozilla 
Subject: Digicert: failure to revoke certificate with previously compromised key

Certificate https://crt.sh/?id=2606438724, issued either at 2020-03-21
00:00:00 UTC (going by notBefore) or 2020-03-21 01:56:31 UTC (going by SCTs), 
is using a private key with SPKI 
4310b6bc0841efd7fcec6ba0ed1f36e7a28bf9a707ae7f7771e2cd4b6f31b5af, which was 
reported to Digicert as compromised on 2020-03-20 02:05:49 UTC (and for which 
https://crt.sh/?id=1760024320 was revoked for keyCompromise soon after 
certificate 2606438724 was issued).

As previously discussed on this list, the visible consensus is that, according 
to the BRs, certificates for which the CA already had evidence of key 
compromise must be revoked within 24 hours of issuance.  That 24 hour period 
has passed for the above certificate, and thus it would appear that Digicert 
has failed to abide by the BRs.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 need is a tool that 
scans after revocation to ensure there are no additional certs with the same 
key.  The frustration is that this was where the cert was issued after our scan 
of all keys but just before revocation.  As a side note, our system blacklists 
the keys when a cert is revoked for key compromise, which means I don't have a 
way to blacklist a key before a cert is ever issued. 

>> I don't think that supports your point, though, so I wonder if I've got the 
>> wrong part.  That last part of Ryan's: "shenanigans, such as CAs arguing 
>> the[y?] require per-cert evidence rather than systemic demonstrations", 
>> seems to me like it's describing your statement, above, that you (only?) 
>> "need to revoke a cert that is key compromised once we're the key is 
>> compromised *for that cert*" (emphasis added).  I don't read Ryan's use of 
>> "shenanigans" as approving of that sort of thing.

I don't think its shenanigans, but I do think it's a pretty common 
interpretation. Such information would help determine the common interpretation 
of this section.  I agree that CAs should scan all certs for the same key and 
revoke where they find them.  Is that actually happening? Do other CAs object 
to there being a lack of specificity if you give the keys without a cert 
attached? 

>> Bim bam bom, all done and dusted, and we can get back to washing our hands. 
That you're *not* doing that is perplexing, and a little disconcerting.

That's an oversimplification of the incident report process. I'm not resisting 
the incident report itself since incident reports are a good and healthy way 
for the public to have transparency into a CAs operation. In fact, I wouldn't 
mind filing one just to give public documentation on what DigiCert is doing for 
revocation.  I was objecting to actually calling this an incident/breach of the 
guidelines since I disagreed with that, and there's a trend where the 
interpretation of these sections seems to evolve over time. My main emphasis 
was that the guidelines are ambiguous and need refinement.  I'd support 
refining them to be more clear, but calling something shenanigans when the 
language is unclear is unfair.

For the SPKI, you're right. The slow part is downloading it from your website. 
I guess I should have said "a link to the key compromise proof" rather than the 
SPKI. The additional time required to do that was 5 hours. Although the 
automation isn't quite complete yet, the end-state goal is to do the following 
when we get a key compromise notification:
1) Run the CSR through a tool and confirm key compromise
2) Have the tool email the impacted subscriber
3) Have the tool process the revocation at the 24 hour mark. 

The two parts that are done is having the tool process the revocation and parse 
out all the key compromises and processing the revocation within 24 hours.  
Unfortunately, we haven't automated the cert problem report yet so we can only 
accept an email.  Once I get the revocation tool working the way I want it, 
we'll add a tool where you can submit a CSR directly and avoid the round trip. 

>>  Even if Digicert would just prefer that I did something differently in my 
>> problem reports in the future -- something that would make it legitimately 
>> easier for Digicert to process my reports, without making my life a misery 
>> (after all, y'all have a lot more resources than I do) -- all you have to do 
>> is ask.  My e-mail address is right there in every problem report I send. 

Nah - although I'd prefer just to get the CSRs in a zip file,  I can work with 
what you send us. In fact, I wouldn't change your process at all since I want 
to accommodate all sorts of ways for people to send us private keys. I'd rather 
not force you to do extra work to send us the keys in a different way as 
anything that creates barriers to key compromise reports is a bad thing. The 
reason I brought up the format is that I'm not sure when the 24 hour clock 
actually kicks off for revocation. Is it 24 hours after we get your email or 24 
hours after we can confirm key compromise?  I've always regarded these as a 
certificate problem report under 4.9.5 (requiring us to kick off the 
investigation) but then revocation should happen 24 hours after we have reason 
to suspect the key compromise is legit. Usually those are the same time, but 
with the email link (and number of keys in the last batch) it may take longer 
to actually do the investigation to show the key is compromised. I think 
there's ambiguity in when that timer starts, and clearing up that ambiguity in 
the CAB forum would be good.  As you pointed out "obtains" can mean different 
things. 

>> The time to say "he

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

[Jeremy Rowley via dev-security-policy]

Yeah  - that’s about the sum of it. I’ll file an incident report.

There are two things worth discussing in general:

  1.  I’m very interested in seeing the Let’s Encrypt response to this issue 
since the biggest obstacle in trying to find all of the keys with the same 
private key is the sheer volume of the certs. Trying to do a comprehensive 
search when a private key is provided leaves some window between when we start 
the analysis and when we revoke.


  1.  Another issue in trying to report keys that aren’t affiliated with any 
cert is that the process becomes subject to abuse. Without knowing a cert 
affiliated with a key, someone can continuously generate keys and submit them 
as compromised. You end up just blacklisting random keys, DDOSing the 
revocation system as it kicks off another request to  search for those keys.  I 
don’t think it’s feasible. This is why 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-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
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 need is a tool that 
scans after revocation to ensure there are no additional certs with the same 
key.  The frustration is that this was where the cert was issued after our scan 
of all keys but just before revocation.  As a side note, our system blacklists 
the keys when a cert is revoked for key compromise, which means I don't have a 
way to blacklist a key before a cert is ever issued.

Matt, Jeremy,

To make sure I understand the timeline correctly:
2020-03-20 02:05:49 UTC - Matt reports SPKI 
4310b6bc0841efd7fcec6ba0ed1f36e7a28bf9a707ae7f7771e2cd4b6f31b5af, associated 
with https://crt.sh/?id=1760024320 , as compromised
2020-03-21 01:56:31 UTC - DigiCert issues https://crt.sh/?id=2606438724 with 
that same SPKI
2020-03-21 02:09:12 UTC - DigiCert revokes https://crt.sh/?id=1760024320
2020-03-23 03:16:18 UTC - DigiCert revokes https://crt.sh/?id=2606438724

Is that roughly correct?

If so, it does seem like an Incident Report is warranted here, so we can 
understand why:
a) https://crt.sh/?id=2606438724 wasn't revoked when 
https://crt.sh/?id=1760024320 was revoked (assuming those timestamps in the CRL 
are accurate)
b) The key wasn't blocklisted as known compromised (if the timestamps are 
incorrect)

That is, it doesn't seem unreasonable that, for situations of key compromise, 
the CA has the necessary data to scan their systems for potential reuse of that 
key. Given DigiCert's data 
lake<https://bugzilla.mozilla.org/show_bug.cgi?id=1526154>, it should be 
possible to scan for issues.

If I've misunderstood the timing here, please feel free to correct. This is 
where the incident report process is useful, and Resolved/Invalid is a 
perfectly fine state to end in.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

Although I’m sure every CA has business continuity plans, I think that extended 
blocked access to every data center they have may not be part of that plan.  
I’m not sure, but I think if the required shelter’s are in place for long 
periods you may start to see problems. Early disclosure sounds like the best 
policy, but I thought the early disclosure requirement may be worth calling out 
in the Mozilla policy. Then again, that really should be standard procedure at 
that point.

From: Ryan Sleevi 
Sent: Friday, March 20, 2020 2:57 PM
To: Jeremy Rowley 
Cc: Kathleen Wilson ; Mozilla 

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 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 can't be 
revoked. Should that be mentioned, requiring CAs to file an incident report as 
soon as the event becomes likely?

Yes. I think those are, quite honestly, much more concerning, because that's 
not about a CA's relationship with an external party, but about a CA's own 
preparedness for disaster. In any event, as with /any/ incident, the sooner 
it's filed, and the more information and context is provided, the more 
effective a response can be.


For the location issue, I think including the locations audited and the 
locations not audited (to the full criteria) as an emphasis of matter would be 
helpful. So maybe an emphasis like we audited the offices in x, y, and z. 
Office z was inaccessible to evaluate criteria 1-n. It give you the list of 
locations and where there were issues in getting access due t o he emergency.

Yup. That is the model WebTrust is using, and that reasonably meets the 
objective here of informing relying parties when the auditor faced limitations 
that should be considered when evaluating their report.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CT2 log signing key compromise

[Jeremy Rowley via dev-security-policy]

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 SCTs are issued. We doubt the 
key was used to sign anything as you'd need to know the CT build to do so. 
However, as a precaution, we ask that you consider all SCTs invalid if the SCT 
was issued from CT2 after 7pm MST on May 2nd . Please let me know what 
questions you have.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CT2 log signing key compromise

[Jeremy Rowley via dev-security-policy]

They would already appear in a previous tree where the head was signed by us.

From: Alex Cohn 
Sent: Sunday, May 3, 2020 5:22 PM
To: Jeremy Rowley 
Cc: Mozilla 
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 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 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 SCTs are issued. We doubt the 
key was used to sign anything as you'd need to know the CT build to do so. 
However, as a precaution, we ask that you consider all SCTs invalid if the SCT 
was issued from CT2 after 7pm MST on May 2nd . Please let me know what 
questions you have.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CT2 log signing key compromise

[Jeremy Rowley via dev-security-policy]

That is a good question though - I think the last signed head was 7pm. That 
would be the actual time when all other certs shouldn't be trusted... 

There is a problem though if you have a bad-acting CA since the notBefore date 
could be before 7pm and the browsers don't check to see 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 signing key compromise

They would already appear in a previous tree where the head was signed by us.

From: Alex Cohn 
Sent: Sunday, May 3, 2020 5:22 PM
To: Jeremy Rowley 
Cc: Mozilla 
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 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 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 SCTs are issued. We doubt the 
key was used to sign anything as you'd need to know the CT build to do so. 
However, as a precaution, we ask that you consider all SCTs invalid if the SCT 
was issued from CT2 after 7pm MST on May 2nd . Please let me know what 
questions you have.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CT2 log signing key compromise

[Jeremy Rowley via dev-security-policy]

Emails crossed paths – I meant 6pm for the last signed head, but I’m double 
checking as I’m not 100% sure on that time.  And you are right – since a 
compromised SCT can have any time it wants, only a real time check on the last 
known good log would be proof of a valid CT. That real time check doesn’t 
exist.  However, there is still the multiple log requirement.


From: Alex Cohn 
Sent: Sunday, May 3, 2020 5:35 PM
To: Jeremy Rowley 
Cc: Mozilla 
Subject: Re: CT2 log signing key compromise

Thank you for the clarification. This would appear to introduce a new 
requirement for clients verifying SCTs from CT2: a get-proof-by-hash call to 
the log server (or a mirror) is now required to know if a SCT from before May 2 
is valid. Do CT-enforcing clients do this in practice today? (I suspect the 
answer is "no" but don't know off the top of my head)

Alex



On Sun, May 3, 2020 at 6:27 PM Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:
They would already appear in a previous tree where the head was signed by us.

From: Alex Cohn mailto:a...@alexcohn.com>>
Sent: Sunday, May 3, 2020 5:22 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>
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 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 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 SCTs are issued. We doubt the 
key was used to sign anything as you'd need to know the CT build to do so. 
However, as a precaution, we ask that you consider all SCTs invalid if the SCT 
was issued from CT2 after 7pm MST on May 2nd . Please let me know what 
questions you have.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CT2 log signing key compromise

[Jeremy Rowley via dev-security-policy]

The key could be easily used if the attacked exported the key and started 
signing SCTs. However, they would be able to use it to sign SCTs in DigiCert’s 
log for fake certs without knowing the full infrastructure.

We will definitely have a full post-mortem on the issue. However, I wanted to 
post early to give everyone a head’s up about the incident and allow the 
browsers to take any action required in protecting relying parties.

I can say we reacted to the vulnerability when we were notified by Salt that it 
impacted our system. However, I’m not sure why we were not notified and did not 
react to the media publication when it first came out. That is a question we 
are digging into.

From: Ian Carroll 
Sent: Sunday, May 3, 2020 5:55 PM
To: Jeremy Rowley 
Cc: Mozilla 
Subject: Re: CT2 log signing key compromise

Hi Jeremy,

Can you clarify why you believe the signing key cannot be easily used? Is there 
a cryptographic limitation in what was disclosed?

Also, do you have plans for a more formal post-mortem? Since vulnerability 
management is usually an organization-wide process, it would be useful to 
understand why it failed here, in the event it could have carried over 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 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 SCTs are issued. We doubt the 
key was used to sign anything as you'd need to know the CT build to do so. 
However, as a precaution, we ask that you consider all SCTs invalid if the SCT 
was issued from CT2 after 7pm MST on May 2nd . Please let me know what 
questions you have.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CT2 log signing key compromise

[Jeremy Rowley via dev-security-policy]

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 happen, either 
another CA compromised the log or another CA was compromised in a manner that 
an attacker could direct issuance through a log running the compromised key. 

Digging into our logs, I think the log should be distrusted for everything 
after 17:00:02 on May 2. This was the last known good treehead. That head was 
published at 5:00:00 on Sunday, May 3. All SCTs after this don't appear in a 
reliable tree.

Jeremy
-Original Message-
From: dev-security-policy  On 
Behalf Of Corey Bonnell via dev-security-policy
Sent: Sunday, May 3, 2020 6:42 PM
To: Mozilla 
Subject: Re: CT2 log signing key compromise

On Sunday, May 3, 2020 at 7:35:44 PM UTC-4, Alex Cohn wrote:
> Thank you for the clarification. This would appear to introduce a new 
> requirement for clients verifying SCTs from CT2: a get-proof-by-hash 
> call to the log server (or a mirror) is now required to know if a SCT 
> from before May 2 is valid. Do CT-enforcing clients do this in practice today?
> (I suspect the answer is "no" but don't know off the top of my head)

Alternatively, if SCTs from other trusted CT logs are available for a given 
certificate (which would be the case with certificates that comply with 
Google/Apple policy by embedding the requisite number of SCTs in the final 
certificate), the timestamps of those SCTs could be used to determine if the 
CT2 SCT was signed before the key was compromised.

Thanks,
Corey
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 private key. The 
worst someone can do isdemonstrate the existence of a cert with a bad 
public key?

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 the site after a TLS 
connection. No requirement for a CSR since we obtained proof of key control 
through a TLS connection with the website. Turned out the handshake didn't 
actually take the key, but allowed the customer to submit a different public 
key without a CSR. We took down the service a while ago - back in November I 
think. I plan to put it back up when we work out the kink with it not forcing 
the key to match the key used in the handshake. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Matt Palmer via dev-security-policy
Sent: Sunday, May 17, 2020 10:37 PM
To: Mozilla 
Subject: Re: Digicert issued certificate with let's encrypts public key

On Mon, May 18, 2020 at 03:46:46AM +, Peter Gutmann via dev-security-policy 
wrote:
> I assume this is ACME that allows a key to be certified without any 
> proof that the entity requesting the certificate controls it?

ACME requires a CSR to be submitted in order to get the certificate issued. 
A quick scan doesn't show anything like "the signature on the CSR MUST be 
validated against the key", but it does talk about policy considerations around 
weak signatures on CSRs and such, suggesting that it was at least the general 
intention of ACME to require signatures on CSRs to be validated.

In any event, given that the certs involved were issued by Digicert, not Let's 
Encrypt, and Digicert's ACME issuance pipeline is somewhat of a niche thing at 
present, I think it's more likely the problem lies elsewhere.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

It was just the one system and situation-specific.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Peter Gutmann via dev-security-policy
Sent: Monday, May 18, 2020 6:31 AM
To: Matt Palmer ; Mozilla 
; Jeremy Rowley 

Subject: Re: Digicert issued certificate with let's 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 the site after a TLS connection. No requirement for a CSR since we 
>obtained proof of key control through a TLS connection with the 
>website. Turned out the handshake didn't actually take the key, but 
>allowed the customer to submit a different public key without a CSR. We 
>took down the service a while ago - back in November I think. I plan to 
>put it back up when we work out the kink with it not forcing the key to match 
>the key used in the handshake.

Thanks, that was the info I was after: was this a general problem that we need 
to check other systems for as well, or a situation-specific issue that affected 
just one site/system but no others.  Looks like other systems are unaffected.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Status of the bugzilla bug list

[Jeremy Rowley via dev-security-policy]

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 
Subject: Status of the bugzilla bug list

All,

I have looked at the list of open bugs in the CA compliance dashboard [0], and 
I was unpleasantly suprised. There's a total of 75 open issues at the moment of 
writing, of which 31 have not seen an update in 4 weeks, and of which again 23 
[1] are not waiting for a planned future CA or Mozilla action; 30% of the open 
issues, spread over 14 CAs. (These 23 include issues that end with actions like 
"A: We will do this" and "B: We will do that at 'date-long-gone'" when there is 
no indication the action has been taken, and no update since.)

Of those 23, 17 have not seen interactions for over 2 months. (!)

The MRSP (v2.7) requires regular updates for incident reports until the bug is 
marked as resolved. This means that a CA MUST actively keep track of the issue, 
even though this is not always understood by CAs [2]. I can understand that it 
is not always clear what information is still needed to close a bug, but please 
ask for this information on the issue when this is not known, so that there are 
no 'zombie'
tickets.

To remedy the issue of 'many long-standing open CA-Compliance issues with 
unclear state', I would like - as a concerned individual and end user of the 
root store - to ask the relevant CAs and Mozilla to check their issues in the 
ca-compliance board [0], check whether the issues are 'solved' or what 
information they need, and update the relevant issues with the updated 
information or ask for said missing information, so that there is a clear 
understanding which issues are resolved and which issues need more information 
/ actions by some party in the issue. As stated before, this process is not 
always clear to all CAs [2], and in my experience explicit communication helps 
a lot in checking what is needed to solve an issue.


Kind regards,

Matthias van de Meent


[0] 
https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_status=__open__
[1] 
https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_id=1593776%2C1605804%2C1623356%2C1550645%2C1625767%2C1502957%2C1620561%2C1575022%2C1590810%2C1578505%2C1463975%2C1496616%2C1614448%2C1559765%2C1606380%2C1532559%2C1599916%2C1551372%2C1610767%2C1575530%2C1597950%2C1597947%2C1597948&bug_id_type=anyexact&list_id=15253621&query_format=advanced
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1613409
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Status of the bugzilla bug list

[Jeremy Rowley via dev-security-policy]

There are others in this same group of pending Mozilla closure:
https://bugzilla.mozilla.org/show_bug.cgi?id=1496616
https://bugzilla.mozilla.org/show_bug.cgi?id=1463975
https://bugzilla.mozilla.org/show_bug.cgi?id=1532559
https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 (Waiting on Wayne)




-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. 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 
Subject: Status of the bugzilla bug list

All,

I have looked at the list of open bugs in the CA compliance dashboard [0], and 
I was unpleasantly suprised. There's a total of 75 open issues at the moment of 
writing, of which 31 have not seen an update in 4 weeks, and of which again 23 
[1] are not waiting for a planned future CA or Mozilla action; 30% of the open 
issues, spread over 14 CAs. (These 23 include issues that end with actions like 
"A: We will do this" and "B: We will do that at 'date-long-gone'" when there is 
no indication the action has been taken, and no update since.)

Of those 23, 17 have not seen interactions for over 2 months. (!)

The MRSP (v2.7) requires regular updates for incident reports until the bug is 
marked as resolved. This means that a CA MUST actively keep track of the issue, 
even though this is not always understood by CAs [2]. I can understand that it 
is not always clear what information is still needed to close a bug, but please 
ask for this information on the issue when this is not known, so that there are 
no 'zombie'
tickets.

To remedy the issue of 'many long-standing open CA-Compliance issues with 
unclear state', I would like - as a concerned individual and end user of the 
root store - to ask the relevant CAs and Mozilla to check their issues in the 
ca-compliance board [0], check whether the issues are 'solved' or what 
information they need, and update the relevant issues with the updated 
information or ask for said missing information, so that there is a clear 
understanding which issues are resolved and which issues need more information 
/ actions by some party in the issue. As stated before, this process is not 
always clear to all CAs [2], and in my experience explicit communication helps 
a lot in checking what is needed to solve an issue.


Kind regards,

Matthias van de Meent


[0] 
https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_status=__open__
[1] 
https://bugzilla.mozilla.org/buglist.cgi?product=NSS&component=CA%20Certificate%20Compliance&bug_id=1593776%2C1605804%2C1623356%2C1550645%2C1625767%2C1502957%2C1620561%2C1575022%2C1590810%2C1578505%2C1463975%2C1496616%2C1614448%2C1559765%2C1606380%2C1532559%2C1599916%2C1551372%2C1610767%2C1575530%2C1597950%2C1597947%2C1597948&bug_id_type=anyexact&list_id=15253621&query_format=advanced
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1613409
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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
Sent: Thursday, May 21, 2020 3:25 PM
To: Daniela Hood 
Cc: Mozilla 
Subject: Re: GoDaddy: Failure to revoke certificate with compromised key within 
24 hours

On Thu, May 21, 2020 at 02:01:49PM -0700, Daniela Hood via dev-security-policy 
wrote:
> Hello Sandy,
> 
> GoDaddy received an email on Friday, May 7, 2020 12:06 UTC, reporting a key 
> compromise, by Sandy. Once received our team started working on making sure 
> that the certificate had indeed a compromised key, the investigation on the 
> certificate finished at that same day Friday, May 7th between 16:54 UTC and 
> 16:55 UTC. 
> After that we followed the Baseline Requirements 4.9.1 That says: "The CA 
> obtains evidence that the Subscriber's Private Key corresponding to the 
> Public Key in the Certificate suffered a Key Compromise;" We obtained the 
> evidence that the key was compromised when we finished our investigation at 
> 16:55 UTC, that was the time we set 24 hours revocation of the certificate, 
> the same was revoked at May 8th at 16:55 UTC.
> We communicated with the reporter as soon as we completed our 
> investigation and informed that the affected certificate would be 
> revoked strictly within 24 hours which we have done and can be 
> confirmed here: https://crt.sh/?id=2366734355

>From what I understand, you received the evidence at May 7, 2020
12:06 UTC, but it took you until 16:55 UTC to confirm that the evidence you've 
received was valid.

I think the 24 hour starts at the time you receive the evidence, not the time 
that you confirm the evidence is valid. Otherwise you can just delay looking at 
the mail for say a week, and still claim that you revoked it in 24 hours.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 URL content types)

Inspired by last month's email threads and Bugzilla issues relating to CA 
Issuers misconfigurations, I've just finished adding a new feature to crt.sh...

https://crt.sh/ca-issuers

Sadly, this highlights plenty of misconfigurations and other problems: PEM 
instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, 
non-existent domain names, connection timeouts.  I encourage CAs to take a look 
and see what they can fix.  (Also, comments welcome :-) ).

While I'm here, here's a quick reminder of some other crt.sh features relating 
to CA compliance issues:
https://crt.sh/ocsp-responders
https://crt.sh/test-websites
https://crt.sh/mozilla-disclosures


From: dev-security-policy  on 
behalf of Ryan Sleevi via dev-security-policy 

Sent: 22 May 2020 21:52
To: Hanno Böck 
Cc: r...@sleevi.com ; dev-security-policy@lists.mozilla.org 

Subject: Re: CA Issuer AIA URL content types

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I believe you've still implied, even in this reply, that this is something 
serious or important. I see no reason to believe that is the case, and I wasn't 
sure if there was anything more than a "Here's a SHOULD and here's people not 
doing it," which doesn't seem that useful to me.

On Fri, May 22, 2020 at 2:52 PM Hanno Böck  wrote:

> Hi,
>
> On Fri, 22 May 2020 09:55:22 -0400
> Ryan Sleevi via dev-security-policy
>  wrote:
>
> > Could you please cite more specifically what you believe is wrong 
> > here? This is only a SHOULD level requirement.
>
> I think I said that more or less:
>
> > > I'm not going to file individual reports for the CAs. Based on 
> > > previous threads I don't believe these are strictly speaking rule 
> > > violations.
>
> I'm not claiming this is a severe issue or anything people should be 
> worried about.
> It's merely that while analyzing some stuff I observed that AIA fields 
> aren't as reliable as one might want (see also previous mails) and the 
> mime types are one more observation I made where things aren't what 
> they probably SHOULD be.
> I thought I'd share this observation with the community.
>
> --
> Hanno Böck
> https://hboeck.de/
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

Doh - how did I miss that?! Thanks Ryan

From: Ryan Sleevi 
Sent: Wednesday, June 17, 2020 4:11:46 PM
To: Jeremy Rowley 
Cc: Mozilla 
Subject: Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content 
types)

It's right there under "Trust Filter" . Very top of the page ;)

e.g. 
https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl&trustedBy=Mozilla&trustedFor=Server+Authentication&dir=v&sort=2&rootOwner=&url=&content=&contentType=

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 revoked and non-TLS/SMIME ICAs?

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, June 17, 2020 5:07 AM
To: dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)

Inspired by last month's email threads and Bugzilla issues relating to CA 
Issuers misconfigurations, I've just finished adding a new feature to crt.sh...

https://crt.sh/ca-issuers

Sadly, this highlights plenty of misconfigurations and other problems: PEM 
instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, 
non-existent domain names, connection timeouts.  I encourage CAs to take a look 
and see what they can fix.  (Also, comments welcome :-) ).

While I'm here, here's a quick reminder of some other crt.sh features relating 
to CA compliance issues:
https://crt.sh/ocsp-responders
https://crt.sh/test-websites
https://crt.sh/mozilla-disclosures


From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 on behalf of Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
Sent: 22 May 2020 21:52
To: Hanno Böck mailto:ha...@hboeck.de>>
Cc: r...@sleevi.com<mailto:r...@sleevi.com> 
mailto:r...@sleevi.com>>; 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
 
mailto:dev-security-policy@lists.mozilla.org>>
Subject: Re: CA Issuer AIA URL content types

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I believe you've still implied, even in this reply, that this is something 
serious or important. I see no reason to believe that is the case, and I wasn't 
sure if there was anything more than a "Here's a SHOULD and here's people not 
doing it," which doesn't seem that useful to me.

On Fri, May 22, 2020 at 2:52 PM Hanno Böck 
mailto:ha...@hboeck.de>> wrote:

> Hi,
>
> On Fri, 22 May 2020 09:55:22 -0400
> Ryan Sleevi via dev-security-policy
> mailto:dev-security-policy@lists.mozilla.org>>
>  wrote:
>
> > Could you please cite more specifically what you believe is wrong
> > here? This is only a SHOULD level requirement.
>
> I think I said that more or less:
>
> > > I'm not going to file individual reports for the CAs. Based on
> > > previous threads I don't believe these are strictly speaking rule
> > > violations.
>
> I'm not claiming this is a severe issue or anything people should be
> worried about.
> It's merely that while analyzing some stuff I observed that AIA fields
> aren't as reliable as one might want (see also previous mails) and the
> mime types are one more observation I made where things aren't what
> they probably SHOULD be.
> I thought I'd share this observation with the community.
>
> --
> Hanno Böck
> https://hboeck.de/
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Clear definition of a "locality"

[Jeremy Rowley via dev-security-policy]

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 locality = city or county. However, before that 
the guidance was that locality = locality= whatever the address lookup during 
verification confirmed was locality.  Before revoking this particular cert, I 
figured we needed a clear working definition on locality since I didn't want a 
subjective review of all certs issued prior to Sept 2019.  Does anyone know of 
a definition to use? We (DigiCert) currently uses ISO 3166-2 to define states, 
but I know even that is not universally held (based on the previous discussion 
about adopting it as the definition).



-Original Message-
From: dev-security-policy  On 
Behalf Of George via dev-security-policy
Sent: Friday, June 26, 2020 3:05 PM
To: dev-security-policy@lists.mozilla.org
Subject: Clear definition of a "locality"

I sent a problem report to rev...@digicert.com regarding the locality field in:

https://crt.sh/?q=12EC8C05667173603367E8F93B7FDCA7EC60F9838EF3B72A4483BAF48DE48F4B

Jeremy Rowley replied stating that he believed the locality was correct as 
there was no clear definition of a locality, can we get a clear definition of 
this?

If these are considered localities then the streetAddress field seems to be 
obsolete? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 the BRs is 
useful because it highlights potentially poor language in the BRs. For example: 

Section 4.9.9:
OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST 
either:
1. Be signed by the CA that issued the Certificates whose revocation status is 
being checked, or
2. Be signed by an OCSP Responder whose Certificate is signed by the CA that 
issued the Certificate whose revocation status is being checked.
In the latter case, the OCSP signing Certificate MUST contain an extension of 
type id-pkix-ocsp-nocheck, as defined by RFC6960
The requirement for no-check only applies in the latter case, which is if the 
OCSP response is signed by an OCSP responder. How would the no-check 
requirement apply if no OCSP responses are being signed by the responder.  If 
the ICAs aren't signing, why does it apply?

Should the OCSP issue be fixed? Definitely. The security issues are apparent. 
Should the BR language be modified for clarity? I think that conversation is 
still ongoing and shutting that down with threats of distrust is counter 
productive. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, July 2, 2020 11:05 AM
To: Rob Stradling 
Cc: Mozilla 
Subject: Re: Question about the issuance of OCSP Responder Certificates by 
technically constrained CAs

On Thu, Jul 2, 2020 at 12:51 PM Rob Stradling via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> On 02/07/2020 17:13, Ryan Sleevi via dev-security-policy wrote:
> > On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell wrote:
> 
> >> If there’s no digitalSignature KU, then the certificate is not a 
> >> OCSP responder certificate due to the technical inability to sign 
> >> OCSP
> responses
> >> that would be accepted by clients conforming to RFC 5280, section
> 4.2.1.12.
> >> Therefore, section 4.9.9 is not applicable for those certificates 
> >> that
> not
> >> express the digitalSignature KU. This is directly relevant to the 
> >> topic
> at
> >> hand.
> >
> > Alternatively: If the OCSPSigning EKU is present, and it lacks 
> > DigitalSignature, it's misissued by containing an invalidEKU.
>
> As Ryan already mentioned, RFC6960 very clearly says:
>"OCSP signing delegation SHALL be designated by the inclusion of
> id-kp-OCSPSigning in an extended key usage certificate extension
> included in the OCSP response signer's certificate."
>
> The presence or absence of the DigitalSignature Key Usage bit does not 
> alter this fact.
>
> RFC6960 doesn't mention the Key Usage extension at all, AFAICT.
>
> https://tools.ietf.org/html/rfc5280#section-4.2.1.12 doesn't use any
> RFC2119 keywords when it says:
>"id-kp-OCSPSigningOBJECT IDENTIFIER ::= { id-kp 9 }
> -- Signing OCSP responses
> -- Key usage bits that may be consistent: digitalSignature
> -- and/or nonRepudiation"
>
> The BRs say...
>"If the Root CA Private Key is used for signing OCSP responses, then
> the digitalSignature bit MUST be set."
>and
>"If the Subordinate CA Private Key is used for signing OCSP responses,
> then the digitalSignature bit MUST be set"
> ...but this is obviously intended to refer to OCSP responses signed 
> directly by the CA (rather than OCSP responses signed by a CA that 
> also masquerades as a delegated OCSP response signer!)
>

Even if a CA wanted to argue that there's no 4.9.9 BR violation (which, as I 
suggested, I would strongly advocate for their distrust, due to the logical 
consequences of such an argument), the KU violation itself can be argued a 
Mozilla violation, using the exact language Corey highlighted.

Recall Section 5.2 of Mozilla Root Policy 2.7:
https://github.com/mozilla/pkipolicy/blob/66ac6b888965aefc88a8015b37d2ee6b5b095fba/rootstore/policy.md#52-forbidden-and-required-practices

"""
CAs MUST NOT issue certificates that have:
...
* incorrect extensions
"""

While a list of possible incorrect extensions is included, if the argument is 
that the EKU doesn't matter because the KU is incorrect for that EKU, then it's 
an argument that the CA has issued a certificate with incorrect extensions. 
Which is still a Mozilla Root Store Policy violation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

Thank you for the clarification – and I definitely agree with you that the time 
to talk about this is now, one the Mozilla list, and not in the incident 
reports. It’s not helpful to have the discussion there since it lacks the 
public benefit.

From: Ryan Sleevi 
Sent: Thursday, July 2, 2020 11: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 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.

That isn't what was said at all, and it doesn't do anyone any good to 
misrepresent it so egregiously.

A CA using the arguments Corey made as part of their CA incident response? 
Absolutely. Because it's a terrible incident response, and a CA arguing that as 
part of an incident response is a CA that is arguing in bad faith, because it's 
the same argument over "intent" that has been shut down over and over.

Separating out the security risk from the applicability of the BRs is useful 
because it highlights potentially poor language in the BRs. For example:

Section 4.9.9:
OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST 
either:
1. Be signed by the CA that issued the Certificates whose revocation status is 
being checked, or
2. Be signed by an OCSP Responder whose Certificate is signed by the CA that 
issued the Certificate whose revocation status is being checked.
In the latter case, the OCSP signing Certificate MUST contain an extension of 
type id-pkix-ocsp-nocheck, as defined by RFC6960
The requirement for no-check only applies in the latter case, which is if the 
OCSP response is signed by an OCSP responder. How would the no-check 
requirement apply if no OCSP responses are being signed by the responder.  If 
the ICAs aren't signing, why does it apply?

Should the OCSP issue be fixed? Definitely. The security issues are apparent.

Good, that's the focus, and for some CAs, based on discussions had before 
filing this incident report, they did not see it as apparent, even after 
Robin's educational highlighting of the security issues nearly a year ago.

Should the BR language be modified for clarity? I think that conversation is 
still ongoing and shutting that down with threats of distrust is counter 
productive.

And I'm not shutting down that discussion. My examination of this incident in 
the first place was triggered by CAs, among others including GlobalSign and 
HARICA, not realizing that this was an existing requirement when I made an 
explicit proposal to clarify this in the BRs, by prohibiting 
`id-kp-OCSPSigning` from being combined with other EKUs. Would that have fixed 
4.9.9? No, and so I'm making sure to also add that to the "Cleanups and 
Clarifications" ballot. And I'm sure the CABF Validation WG will no doubt, in 
light of this, realize that we need an "OCSP Responder" profile to go with the 
other profiles being worked on.

The threat of distrust isn't over discussing how to make this *better*. That's 
of course welcome to highlight where requirements aren't clear. It would be 
entirely appropriate a CA would, as part of their incident response, argue this 
is *not an incident*. I would hate if CAs, particularly those in the CA 
Security Council, were to try and coordinate and argue it's not an issue. I 
would especially hate if CAs were to point to Corey's arguments in particular, 
as a means of trying to create a parallel construction for why they did what 
they originally did (which is, more likely, explained by just not reading/being 
aware of the requirements), especially if trying to avoid the need to come up 
with a plan to revoke these CAs.

Corey's not making this argument as part of an incident response, and so I *do* 
appreciate his attempt to highlight issues to improve. However, I'm trying to 
make it clear that the argument for why this is not an issue is not valid, and 
if a CA were to try to argue WontFix/Invalid (or, more aptly, "won't revoke, we 
don't think it's relevant"), that'd be an absolutely awful response.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mandatory reasonCode analysis

[Jeremy Rowley via dev-security-policy]

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 Requirements and was 
either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, 
the CRLReason MUST NOT be certificateHold (6).

Which made me think the language applied only to CRLs and OCSP issued after 
9-30. However, the language does only reference certificateHold and not the 
inclusion of reasonCode language. 

That was the analysis I had anyway - that any CRLs and OCSP published after 
9-30 had to have  reasonCode.  

-Original Message-
From: dev-security-policy  On 
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-security-policy@lists.mozilla.org
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Mandatory reasonCode analysis

[Jeremy Rowley via dev-security-policy]

That's probably true since CRL entries are published instead of issued and they 
don't have a notBefore date.

Regardless, I can see why someone would read it as requiring an update for all 
next published CRLs/OCSP given the historical way the BRs worked.

To be safe, we did update all of the DigiCert CRLs/OCSP for ICAs capable of 
issuing TLS. Looks like your report is flagging the legacy Symantec ICAs that 
are no longer trusted for TLS and are part of a root removal request.

From: Rob Stradling 
Sent: Wednesday, September 30, 2020 10:56 AM
To: Mozilla ; Jeremy Rowley 

Subject: Re: Mandatory reasonCode analysis

> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was 
> either issued on-or-after 2020-09-30 or has a notBefore on-or-after 
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).

I think "was either issued on-or-after 2020-09-30 or has a notBefore 
on-or-after 2020-09-30" is talking about "a Certificate not subject to these 
Requirements", not about when the CRL was issued.


From: dev-security-policy 
mailto:dev-security-policy-boun...@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 email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


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 Requirements and was 
either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, 
the CRLReason MUST NOT be certificateHold (6).

Which made me think the language applied only to CRLs and OCSP issued after 
9-30. However, the language does only reference certificateHold and not the 
inclusion of reasonCode language.

That was the analysis I had anyway - that any CRLs and OCSP published after 
9-30 had to have  reasonCode.

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com<mailto:r...@sectigo.com>
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jeremy Rowley via dev-security-policy]

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 limitation. If 
it's not addressed in this update, adding clarification on domain verification 
reuse for SMIME would be a good improvement on the existing policy.

-Original Message-
From: dev-security-policy  On 
Behalf Of Ben Wilson via dev-security-policy
Sent: Wednesday, December 2, 2020 2:22 PM
To: Ryan Sleevi 
Cc: Doug Beattie ; Mozilla 

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

See my responses inline below.

On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi  wrote:

>
>
> On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> wrote:
>
>> See responses inline below:
>>
>> On Tue, Dec 1, 2020 at 11:40 AM Doug Beattie 
>> > >
>> wrote:
>>
>> > Hi Ben,
>> >
>> > For now I won’t comment on the 398 day limit or the date which you
>> propose
>> > this to take effect (July 1, 2021), but on the ability of CAs to 
>> > re-use domain validations completed prior to 1 July for their full 
>> > 825 re-use period.  I'm assuming that the 398 day limit is only for 
>> > those domain validated on or after 1 July, 2021.  Maybe that is 
>> > your intent, but the wording is not clear (it's never been all that 
>> > clear)
>> >
>>
>> Yes. (I agree that the wording is currently unclear and can be 
>> improved, which I'll work on as discussion progresses.)  That is the 
>> intent - for certificates issued beginning next July--new validations 
>> would be valid for
>> 398 days, but existing, reused validations would be sunsetted and 
>> could be used for up to 825 days (let's say, until Oct. 1, 2023, 
>> which I'd advise against, given the benefits of freshness provided by 
>> re-performing methods in BR 3.2.2.4 and BR 3.2.2.5).
>>
>
> Why? I have yet to see a compelling explanation from a CA about why 
> "grandfathering" old validations is good, and as you note, it 
> undermines virtually every benefit that is had by the reduction until 2023.
>

I am open to the idea of cutting off the tail earlier, at let's say, October 1, 
2022, or earlier (see below).  I can work on language that does that.


>
> Ben, could you explain the rationale why this is better than the 
> simpler, clearer, and immediately beneficial for Mozilla users of 
> requiring new validations be conducted on-or-after 1 July 2021? Any CA 
> that had concerns would have ample time to ensure there is a fresh 
> domain validation before then, if they were concerned.
>

I don't have anything yet in particular with regard to a 
pros-cons/benefits-analysis-supported rationale, except that I expect push-back 
from SSL/TLS certificate subscribers and from CAs on their behalf. You're 
right, CAs could take the time between now and July 1st to obtain 398-day 
validations, but my concern is with the potential push-back.

Also, as I mentioned before, I am interested in proposing this as a ballot in 
the CA/Browser Forum and seeing where it goes. I realize that this issue might 
come with added baggage from the history surrounding the validity-period 
changes that were previously defeated in the Forum, but it would still be good 
to see it adopted there first. Nonetheless, this issue is more than ripe enough 
to be resolved here by Mozilla as well.



>
> Doug, could you explain more about why it's undesirable to do that?
>
>
>> >
>> > Could you consider changing it to read more like this (feel free to 
>> > edit as needed):
>> >
>> > CAs may re-use domain validation for subjectAltName verifications 
>> > of dNSNames and IPAddresses done prior to July 1, 2021 for up to 
>> > 825 days
>> > > accordance with domain validation re-use in the BRs, section  4.2.1>.
>> CAs
>> > MUST limit domain re-use for subjectAltName verifications of 
>> > dNSNames
>> and
>> > IPAddresses to 398 days for domains validated on or after July 1, 2021.
>> >
>>
>> Thanks. I am open to all suggestions and improvements to the language.
>> I'll
>> see how this can be phrased appropriately to reduce the chance for 
>> misinterpretation.
>>
>
> As noted above, I think adopting this wording would prevent much 
> (any?) benefit from being achieved until 2023. I can understand that 
> 2023 is better than "never", but I'm surprised to see an agreement so 
> quickly to that being desirable over 2021. I suspect there's ample 
> context here, but I think it would benefit from discussion.
>

The language needs to be worked on some more.  As I note above, we should come 
up with a cutoff date that is before 2023. It seems that two years is too long 
to wait for the last 825-day validation to expire when there are domain 
validation methods that work in a matter of seconds.


>
>
>> > From a CA perspect

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

Without the private key, im not sure how we're supposed to confirm key 
compromise. 

> On Dec 25, 2017, at 3:32 AM, Adrian R. via dev-security-policy 
>  wrote:
> 
> The BattleNet app needs to be installed and running, i am logged in with a 
> battlenet account.
> 
> the public certificate is attached below and i don't know how to get the 
> private key from inside the app, but it must be there since it runs as local 
> webserver on 127.0.0.1
> 
> Adrian R.
> 
> -BEGIN CERTIFICATE-
> MIIFbTCCBFWgAwIBAgIQCn+uUpLudsH09lYYIPTK5DANBgkqhkiG9w0BAQsFADBw
> MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
> d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
> dXJhbmNlIFNlcnZlciBDQTAeFw0xNzEyMTMwMDAwMDBaFw0xODEyMTgxMjAwMDBa
> MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZJ
> cnZpbmUxJTAjBgNVBAoTHEJsaXp6YXJkIEVudGVydGFpbm1lbnQsIEluYy4xGDAW
> BgNVBAMTD2xvY2FsYmF0dGxlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
> AQoCggEBAL7pCsdGFhOe0aTk/1zPuBhD+5dc4Lg6VMg+Y+HRfJv9nlLfFoDKS2dy
> 3cwPTW3NaQqNRhGug5ODBsoLUOI7heT4tiv91yQ+OlIFENsS1vWgba85ifIKt3pS
> PG6kLc96nZ3JLpU4qjXOiF14/BECtNfBnIRsq60Vd/STWSNo84XrEvYBraTXT7Pg
> kkU2DFeUcl9pvfcsLmtJ4tUk1E1euL7cqQxN5LRr+6hPyhN1rqB5SEaWoIaUd4OD
> stR4H8RbxCXunIUS3o1O12cWAt4q4jDTay+8Bqy0sYGPvlLSOHMSrWHshpMGMVUL
> Plh5pKpXQn78usEyTw4O3hDPFnHv4McCAwEAAaOCAf0wggH5MB8GA1UdIwQYMBaA
> FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBTlPRA/nSH/T/W5QfGmpEwp
> YI/YEzAvBgNVHREEKDAmgg9sb2NhbGJhdHRsZS5uZXSCE3d3dy5sb2NhbGJhdHRs
> ZS5uZXQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
> BQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20v
> c2hhMi1oYS1zZXJ2ZXItZzYuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2Vy
> dC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9
> bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMw
> CAYGZ4EMAQICMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAh0dHA6Ly9v
> Y3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMuZGln
> aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5jcnQw
> DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAaAidMTizU/KDox3Rd/Ak
> 9u/iGbGjwssc9582FoRQVBdOxVkvxNWy/+9As/v6HUhZhWRBYOPMwvMSYBufNcdq
> +zrEK8uJU4T0zI684pqzVsPwpFw3t9JzcdTZGScrD5//7fAkTql4YW9FGTyWz4ka
> qXwt19R615xxFBGPt25jaB2vZHXrHl3v49GkntFpvlKLwhlidcrVg1F3px4di7c3
> OR82PbAnjipHzg0KXZWZdbRh3IliYgoH31ygkuVKLd3HrmsDIXYe+zN/nWLA6tw0
> O9NKI7THpe62be+Anarbvj9x3/78+rojqMl/oXpiNEKl/lOYuFKomtt+sA7NxNL0
> kg==
> -END CERTIFICATE-
> 
> 
> 
>> On Monday, 25 December 2017 12:17:36 UTC+2, Hanno Böck  wrote:
>> On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
>> "Adrian R. via dev-security-policy"
>>  wrote:
>> 
>>> on any computer with BattleNet installed and active go to this url:
>>> 
>>> https://127.0.0.1:22886/
>>> and currently it uses this certificate... which doesn't appear on
>>> crt.sh yet
>> 
>> I'm not able to reproduce this. Right now if I install battle.net I
>> don't get a listening port on 22886 at all. Can you please export the
>> certificate and send it here?
>> 
>> 
>> -- 
>> Hanno Böck
>> https://clicktime.symantec.com/a/1/KJ0TLgnYKZG-ejHetbcPBoY5C8CMG9KRMt9YyMceby0=?d=fO2IqqaZwQxg4Bl6je7HihqX4BwX3heoNAZ6Ao3Bbh-ZpLB4qQgiU5CmyPuOD8NWCz9gv85sYbbcZ1l1t8R3UTKhyDW52L-jg9Vz2Hyl9vfOgHz_AA9HJQHNOcb2eZ4OhJR5fnPamqCiwKn8b1nV0pu3xM2zoa4Q0lb4ATr99pNs_wVygwgGJQ5eaO6zSL9wsXXNl9AatjLXtzFyGDgWy1yQd34gBaX4k_nzBA4nU0Pq4ZiA9h-VPA_zmRkR5eDje0sj16DMWt25rv6JF1kWlONq20bzzGc8lUw1WXoO26AHtVdjGzQYYW33-MOaaablM8Ka4yXt81k8DvnPhuS3CI36-dY5vwg5IbGzdLcur26YRYofF9jujrtV8NSkEPsUjS3VuwYXPwsZJk4NRq8350X8PFMC6Ij8P537O4KivC9qADjbjoJod8hYsDHq-yBH6OAoqtUk2sa-RFDa2jJL2iCOahUFGPrzI3nS7hUytgV8nLz-im2zgmlj8SugEWHP3uti6uJLAnqu5H4ncJhMQLvmYQ%3D%3D&u=https%3A%2F%2Fhboeck.de%2F
>> 
>> mail/jabber: ha...@hboeck.de
>> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/5e71ho7sLxNPxkirDsU3_VlvVsHU9OQ7rJ9O5JzCRNo=?d=fO2IqqaZwQxg4Bl6je7HihqX4BwX3heoNAZ6Ao3Bbh-ZpLB4qQgiU5CmyPuOD8NWCz9gv85sYbbcZ1l1t8R3UTKhyDW52L-jg9Vz2Hyl9vfOgHz_AA9HJQHNOcb2eZ4OhJR5fnPamqCiwKn8b1nV0pu3xM2zoa4Q0lb4ATr99pNs_wVygwgGJQ5eaO6zSL9wsXXNl9AatjLXtzFyGDgWy1yQd34gBaX4k_nzBA4nU0Pq4ZiA9h-VPA_zmRkR5eDje0sj16DMWt25rv6JF1kWlONq20bzzGc8lUw1WXoO26AHtVdjGzQYYW33-MOaaablM8Ka4yXt81k8DvnPhuS3CI36-dY5vwg5IbGzdLcur26YRYofF9jujrtV8NSkEPsUjS3VuwYXPwsZJk4NRq8350X8PFMC6Ij8P537O4KivC9qADjbjoJod8hYsDHq-yBH6OAoqtUk2sa-RFDa2jJL2iCOahUFGPrzI3nS7hUytgV8nLz-im2zgmlj8SugEWHP3uti6uJLAnqu5H4ncJhMQLvmYQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

I think this raises a question on what level of investigation and assumption is 
required by the ca. Let's encrypt, for example, requires submission of the 
private key for revocation (https://letsencrypt.org/docs/revoking/). Is simply 
providing a reference rather than the key sufficient?

On Dec 25, 2017, at 7:52 AM, Adrian R. via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

1) get a virtual machine
2) install windows, install the Blizzard BattleNet client.
3) create a BattleNet account with any email address - it's free, 
subscription/payment is not required for this.
4) login in the BattleNet app client with the account from step 3.

5) after the main BattleNet interface appears and shows that the user is 
properly logged in to their BattleNet account, open
https://127.0.0.1:22886/
in a web browser on the same virtual machine

result: this screen appears: 
https://clicktime.symantec.com/a/1/H8EylvFRu5AobRkYFh6nEMe_PZIqmSax2Rvqek2FeJs=?d=1yfch_0HocrSV8WeVgZeGsaOOneJ-8cF9bP7yzmp3HXKFGdjeJepYJf6HznnulZj_1Hv1P6Nn-z52PWlor45BiQi65emSMiq-1FjmlLPbEJBtMBbrUogI-Fp6ObsZErl07MAEKeXnIGAYXu493v19485GnXENM8m8015gWJTQdTruz3ruoXnJWdgFJOmflAh0pAb96BgaUR0o3r4BfbPSjVEuaW3jwhMObKUSCA8KQhf20VbylP8ssdWsAlXVpURT5gn4xW12jWxlyLw8Wdo-O5i5iN42A0yKRO3nel-TAJKnwHG0jjPGK9JrCbzjOttwrRwEpdAsa0nBiwHtSqNpBTHtj4vUi-H1XO01dG2eqm6SJgI-ZhQBPSRUgjoHicpibap-jFCjemQVsIxzJMxH_mrPbvx2JXc3bPaMsi5Qyu97ZVLxNl9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D&u=https%3A%2F%2Fimgur.com%2Fv5vqedX


On Monday, 25 December 2017 16:44:03 UTC+2, Jeremy Rowley  wrote:
Without the private key, im not sure how we're supposed to confirm key 
compromise.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/7yhaM2O2nJci9TxwV_RD8qfnr-mmoGnbt-5pz2kQ8pA=?d=1yfch_0HocrSV8WeVgZeGsaOOneJ-8cF9bP7yzmp3HXKFGdjeJepYJf6HznnulZj_1Hv1P6Nn-z52PWlor45BiQi65emSMiq-1FjmlLPbEJBtMBbrUogI-Fp6ObsZErl07MAEKeXnIGAYXu493v19485GnXENM8m8015gWJTQdTruz3ruoXnJWdgFJOmflAh0pAb96BgaUR0o3r4BfbPSjVEuaW3jwhMObKUSCA8KQhf20VbylP8ssdWsAlXVpURT5gn4xW12jWxlyLw8Wdo-O5i5iN42A0yKRO3nel-TAJKnwHG0jjPGK9JrCbzjOttwrRwEpdAsa0nBiwHtSqNpBTHtj4vUi-H1XO01dG2eqm6SJgI-ZhQBPSRUgjoHicpibap-jFCjemQVsIxzJMxH_mrPbvx2JXc3bPaMsi5Qyu97ZVLxNl9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

I’m pretty sure EA revoked the cert.

> On Dec 25, 2017, at 9:23 AM, Hanno Böck  wrote:
> 
> On Mon, 25 Dec 2017 14:43:21 +
> Jeremy Rowley via dev-security-policy
>  wrote:
> 
>> Without the private key, im not sure how we're supposed to confirm
>> key compromise. 
> 
> I've pinged a few people with the right skillset to try to extract the
> key. But if there are people here who feel capable feel free. (I already
> tried the "simple" means, e.g. grepping through files.)
> 
> But one question: In the case of EA the cert got revoked and nobody
> asked for the key as evidence. What happened there? Did EA ask for the
> revocation? (I made them aware, but I have no knowledge of what happened
> afterwards.)
> 
> -- 
> Hanno Böck
> https://clicktime.symantec.com/a/1/7E2647SolTSFOrmTr1pTA6SaNlzWBEeOvNPzQjcoj-Q=?d=umuIBG9-qCSr0Ylk6iYyIG3WeDTsVZikMcWOz_90PD3etIywoX7mdbgM5-o7RmsLsolZOKJ5Yd7icx5CeHssMAD1UiN3APXXUDDjiwPDtMurIvGC1HUEmDwsAqBNjurJb-MIs_jopfZdcgY8mxha-DU3cggVxUKUpNesVOFzY4crbfh1T7v41ePXIqcjijQ5aiIrkZW7KPQhtK0KI34OyF_MPpj2n6Qwe3uXjjiKkflcD6tc0TslmbWo45ySkZr4IN9bmDJwyvSkZBodxAx7nt14NKzoWv2Mva865UkPqyNQF_sU7EOLF98PY4vHaeQFD-z9YZXHQxZjsTCqILJKF6XLJBIUOlZRa_LrXPQ8DxHY7YqNM4c8olIBYR8DWed9-LY-7juzWP3pT-3XoQanCUnEbUsgq1BNL8yQ_OU%3D&u=https%3A%2F%2Fhboeck.de%2F
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

BTW - this certificate was revoked.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Mark Steward via dev-security-policy
Sent: Friday, December 29, 2017 11:30 AM
To: Matthew Hardeman 
Cc: mozilla-dev-security-policy

Subject: Re: Certificates with shared private keys by gaming software (EA
origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Part of the trouble in relying upon the name alone is that on many 
> OS's (maybe all -- at least all the ones that matter for client side 
> work) can have localhost overridden to mean other things.
>
>
The main issue I see is that it effectively breaks SOP. It's not reasonable
to expect a user to know what app is listening on what port whenever a
browser connects, or to ensure that only Battle.net could listen on 28866.


> ...



If I recall correctly, this is actually more of a thing for WebSockets.
>
> If my recollection is correct, Chrome already considers 
> http://localhost or is it http://127.0.0.1 to be a secure origin in 
> nature.  Thus, code which arises from a request to localhost is 
> treated as running within a secure context, even if it is not wrapped 
> in a TLS connection.  (You can run javascript and access APIs in such 
> circumstances on localhost via HTTP when ordinarily Chrome would 
> require HTTPS to enable that access.)
>
> However...  That doesn't help the web developer who is trying to 
> access a WebSocket service on localhost.  While Chrome regards the 
> localhost as a secure origin, WebSockets in Chrome (and every other 
> mainstream browser?) require the connection to be a TLS wrapped one, 
> regardless of whether or not it's from a secure origin.
>
> (I wonder if they even wrote a protocol handler for non-secure web 
> sockets?  At the moment, it's Christmas and I'm being too lazy to 
> look.)
>
>
If by non-secure websockets you mean ws://, then yes, and Chrome is lax here
in that it allows access to ws://localhost from https:// without logging a
Mixed Content warning (Firefox only allows ws://localhost from http://).

I think the real issue is (anticipated) fallout of the move to HTTPS by
default, possibly along with the deprecation of Flash. I don't think there's
a clean solution for creating a socket from a website to an app on the local
machine, except maybe via WebRTC?


Mark
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Trustico / Digicert Mass Revocation

[Jeremy Rowley via dev-security-policy]

I was planning on posting something about this later today. Give me a couple
hours to drink a lot of caffeine, and I'll update the entire community.

-Original Message-
From: dev-security-policy

On Behalf Of Richard Moore via dev-security-policy
Sent: Wednesday, February 28, 2018 6:43 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Trustico / Digicert Mass Revocation

This is likely to be of interest to people on this list. It sounds like a
mass revocation with little detail as to why:

https://clicktime.symantec.com/a/1/3YSPus91If0F4QLt9s8RPcG2iwzR069FeUAuBImae
-g=?d=DqWu_M8WJ2qph8IsqVGHqR6CU4Opbs4BkefsCUF0n3c5VCt5wNeaTl-83TPIPMOl8eSn32
Y-8r5NsphW1nDbi9aPBTfA80VexbVVWOd5kaYi_h9sh52_qwVei9J0lZXcwaDTNVzX87AknHJyrQ
ldsnELqHWOOjNxbXFNHUxpQO1894OkxeYsPSBXLT4GwLWIbegHvJhicKrvvMvqhX6p-zKbEOUucz
S23xLamM90JNEX-LQpGZFbLoKewC0PcoH0fxgX4mfy8NGe-QbHTS1X24NBJVBBtHsaV5lsW3QTYh
lZcIerq9x3ocUhEd1D_WFpgDY1qJxwFn-wkTHY99HtKFUV0OsPPqK7-4DnEigJTZZTYCsTxGrm4x
Ec8yJSIx4pimYFQLAvMi9WU6ozFP-MtyygjWr99moEBtPzYoNvv0B69zxYtlpt5u36Q7Zsptkg8e
Aub6cvjvQV&u=https%3A%2F%2Fwww.reddit.com%2Fr%2Fsysadmin%2Fcomments%2F80uaq3
%2Fdigicert_certificates_being_revoked%2F
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/hevEOAeNWurTjMxHsnssuny2YV82QCOCfA-ZsONcg
ac=?d=DqWu_M8WJ2qph8IsqVGHqR6CU4Opbs4BkefsCUF0n3c5VCt5wNeaTl-83TPIPMOl8eSn32
Y-8r5NsphW1nDbi9aPBTfA80VexbVVWOd5kaYi_h9sh52_qwVei9J0lZXcwaDTNVzX87AknHJyrQ
ldsnELqHWOOjNxbXFNHUxpQO1894OkxeYsPSBXLT4GwLWIbegHvJhicKrvvMvqhX6p-zKbEOUucz
S23xLamM90JNEX-LQpGZFbLoKewC0PcoH0fxgX4mfy8NGe-QbHTS1X24NBJVBBtHsaV5lsW3QTYh
lZcIerq9x3ocUhEd1D_WFpgDY1qJxwFn-wkTHY99HtKFUV0OsPPqK7-4DnEigJTZZTYCsTxGrm4x
Ec8yJSIx4pimYFQLAvMi9WU6ozFP-MtyygjWr99moEBtPzYoNvv0B69zxYtlpt5u36Q7Zsptkg8e
Aub6cvjvQV&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-polic
y


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

Hi everyone,

 

I wanted to share an incident report regarding the revocation of certain
certificates ordered through a reseller.

 

On February 2nd, 2018, we received a request from Trustico to mass revoke
all certificates that had been ordered by end users through Trustico.
Unfortunately, the email was not sent to the appropriate certificate problem
reporting channels and did not surface immediately so we're delayed in
sharing the concerns and information. Once we were alerted, the team kicked
off a debate that I wanted to bring to the CAB Forum. Basically, our
position is that resellers do not constitute subscribers under the Baseline
Requirement's definitions (Section 1.6.1). As such, we needed to confirm
that either the key was compromised or that they revocation was authorized
by the domain holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.  

 

Later, the company shared with us that they held the private keys and the
certificates were compromised, trying to trigger the BR's 24-hour revocation
requirement.  However, we insisted that the subscriber must confirm the
revocation request or there must be evidence of the private key compromise. 

 

Normally, we permit partners to revoke and manage the certificates freely on
behalf of their customer, with DigiCert providing all validation and
issuance services. However, the sheer number of revocation requests (50k)
and allegation of compromise triggered concerns around the impact to the web
and browser users. Therefore, this was categorized as high risk, especially
considering the relationship between Trustico and DigiCert is terminating.

 

On 2/27/2018, at my request for proof of compromise, we received a file with
23k private keys matched to specific Trustico customers. This definitely
triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
Once we received the keys, we confirmed that these were indeed the matching
private keys for the reported certificates. We will be revoking these
certificates today (February 28th, 2018).

 

At this time, Trustico has not provided any information about how these
certificates were compromised or how they acquired the private keys. As is
standard practice for a Certificate Authority, DigiCert never had possession
of these private keys.

 

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.

 

DigiCert sent out emails to the affected customers in order to notify them
that their certificate(s) are being revoked. This revocation only affects
those customers and there is no additional exposure that we are aware of at
this time, nor any reason to believe there is.  

 

This raises a question about the MDSP policy and CAB Forum requirements. Who
is the subscriber in the reseller relation?  We believe this to be the key
holder. However, the language is unclear. I think we followed the letter and
spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot
that clarifies the subscriber in a reseller relationship.

 

This also brings up a ballot about the level of due diligence required for
cert revocation. We generally believe that the private key or demonstration
of domain control is sufficient to request revocation. Others are at the CAs
discretion. Should we clarify what the due diligence looks like? Are there
other things we should have done or been doing? 

 

What kind of transparency would the Mozilla community like around this
issue? There aren't many more facts than I shared above, but there is a lot
of speculation. Let me know what I can share to help alleviate confusion and
answer questions.

 

Jeremy

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

I believe transparency is the best policy.  I think it'd be helpful to the 
community if we could post the email exchange about the revocation. We can 
redact the agreement termination portions if you'd like, but that'd give a lot 
more clarity around what's going on. Do I have your permission to post those 
emails?

-Original Message-
From: dev-security-policy 
 On 
Behalf Of google.manager--- via dev-security-policy
Sent: Wednesday, February 28, 2018 11:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: How do you handle mass revocation requests?

Jeremy,

Today many of our customers experienced lengthy delays when attempting to 
contact us via phone, e-mail and live chat. The reason for the delays were due 
to an unexpected e-mail that DigiCert sent to our customers containing some 
inaccurate information. We were not informed that the e-mail would be sent and 
were caught by surprise. We had disabled this e-mail within your control panel 
and opted to send our own notices, though you took it upon yourselves to send 
my personal details to 20,000 customers.

We didn't authorise DigiCert to contact our customers and we didn't approve the 
content of their e-mail. At no time had any private keys been compromised, nor 
had we ever informed to you that any private keys had been compromised. During 
our many discussions over the past week we put it to you that we believe 
Symantec to have operated our account in a manner whereby it had been 
compromised. Your usage of the word compromise has been twisted by you to your 
benefit and is absolutely defamatory.

We believe the orders placed via our Symantec account were at risk and were 
poorly managed. We have been questioning Symantec without response as to 
concerning items for about a year. Symantec simply ignored our concerns and 
appeared to bury them under the next issue that arose.

There are a range of issues that Trustico intends to investigate via legal 
means.

In good conscience we decided it wasn't ideal to have any active SSL 
Certificates on the Symantec systems, nor any that didn't meet our stringent 
security requirements. Our concerns also relate to the upcoming distrust of all 
Symantec SSL Certificate brands within Google Chrome and the reasoning behind 
it. The same management team responsible for that situation is duly employed at 
DigiCert and are fully managing our account, causing grave concern on our part 
as it appears to be business as usual with a new name. We were also a victim 
whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were 
asked to keep the matter quiet, under a confidentially notice.

We had implemented a system to ensure that all customers would receive a 
replacement SSL Certificate, though today it had failed to perform this 
function.

In our view it is absolutely critical that an SSL Certificate performs its 
intended function. Symantec's issue with Google appeared to seal that deal, 
whereby they will all eventually fail due to distrust. In accordance with CAB 
Forum guidelines we acted to immediately revoke active SSL Certificates whereby 
trust was questionable.

Trustico absolutely distrusts the Symantec brand due to the issues that forced 
Symantec into having to hand over its entire authentication business to an 
alternate CA and a range of issues beforehand. Though, Symantec was ultimately 
acquired by DigiCert - though now DigiCert appears to be influenced by the 
Symantec management team - that to date still is managing our account. Trustico 
stopped offering the Symantec brands early February after a meeting with your 
Symantec management team, whereby they had disclosed to us that various 
reckless issues had occurred (recording available).

We realize that this mass revocation is bothersome and time consuming for all 
that have been affected. We're working to contact all customers to get orders 
replaced as priority and working through a backlog of enquiries. 

Unfortunately, things didn't go very well for us today and we are extremely 
sorry for all the confusion and inconvenience that has been caused. We were 
relying on systems that would easily replace and issue SSL Certificates 
automatically, though that didn't occur and we ended up in quite a mess. 
DigiCert didn't work with us to understand the issues and resolve them, we felt 
we were at a dead end.

We'll be following up again shortly with an update surrounding what occurred 
and more information about where we experienced failures. In the meantime, our 
staff are concentrating on getting SSL Certificates issued as quickly as 
possible from a reputable and trusted CA.

As for the question of who is the subscriber, well ultimately that came down to 
the agreement that we had made with you and the agreement on the website. The 
conditions of the subscriber agreement were not honoured by you when it came to 
our requests anyway – so it’s hard to comment on who you refer to be a 
subscriber – even thou

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

I agree with the OV, EV, and IV. Admittedly, DV certs, which constitute almost 
all the certs, are relatively new to DigiCert so that's partly where the 
question arises. We identified it as the key holder or the domain holder. 
Hence, we'd revoke with confirmation of a domain validation. The reseller 
could be the subscriber, but I'm not sure how we tell with DV certs. This is 
especially with legacy Symantec customers where we are still trying to 
establish the personal relationship and understand their use cases, 
communication expectations, etc.

-Original Message-
From: Peter Bowen 
Sent: Wednesday, February 28, 2018 12:14 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 9:37 AM, Jeremy Rowley via dev-security-policy 
 wrote:
> Once we were alerted, the team kicked
> off a debate that I wanted to bring to the CAB Forum. Basically, our
> position is that resellers do not constitute subscribers under the
> Baseline Requirement's definitions (Section 1.6.1). As such, we needed
> to confirm that either the key was compromised or that they revocation
> was authorized by the domain holder (the subscriber) prior to revoking
> the certificate. The certificates were not alleged as compromised at that 
> time.

> This raises a question about the MDSP policy and CAB Forum
> requirements. Who is the subscriber in the reseller relation?  We
> believe this to be the key holder. However, the language is unclear. I
> think we followed the letter and spirit of the BRs here, but I'd like
> feedback, perhaps leading to a ballot that clarifies the subscriber in a 
> reseller relationship.

For certs with subject identity information (commonly called IV, OV, and EV 
certs), there is no question about the subscriber.  The Subscriber is the 
entity identified in the subject: "The Subject is either the Subscriber or a 
device under the control and operation of the Subscriber."

For certificates without subject identity information (DV certificates), the 
certificate does not list the subscriber.  However the CA clearly knows the 
subscriber, as the subscriber is the "natural person or Legal Entity to whom a 
Certificate is issued and who is legally bound by a Subscriber Agreement or 
Terms of Use"

In some cases the "reseller" might be the subscriber if the reseller is a 
hosting company and is the one that accepts the subscriber agreement but in 
the traditional reseller model their customer is the subscriber as the 
reseller's customer is the one accepting the subscriber agreement.

Given that DigiCert appears to have contact information for the Trustico 
customers, that suggests that the Trustico customer is likely the subscriber, 
but looking at IV/OV/EV certificates (if any) should tell for sure.

Thanks,
Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

The end user agreed to the subscriber agreement, not Trustico. Our analysis 
follows what Peter B. posted – the subscriber is the “natural person or Legal 
Entity to whom a Certificate is issued and who is legally bound by a Subscriber 
Agreement or Terms of Use"—which in this case was Trustico’s customers.  In 
addition, we felt that given (1) the number of certificates Trustico was asking 
us to mass-revoke and (2) the lack of any substantiation of why Trustico 
thought the certs were “compromised,” we needed more information before 
revoking. At the minimum, it warranted alerting the contact for each 
certificate that revocation was imminent.

 

I also agree that there’s no problem with the way or that the keys were 
provided to DigiCert for cert revocation. I certainly don’t want to discourage 
revocation of compromised certs!  My main question is how do you handle these 
things? The process at scale should not be different if a reseller requests 
revocation compared to any other security researcher. The question is how you 
handle the this volume of revocations when its happen? I’ve never received a 
revocation request of this magnitude before so I’m seeking the wisdom of the 
community in what we do.

 

I’m happy to share any of the details I can. 

 

Jeremy

 

 

From: Ryan Sleevi  
Sent: Wednesday, February 28, 2018 11:58 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

 

 

 

On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

On February 2nd, 2018, we received a request from Trustico to mass revoke
all certificates that had been ordered by end users through Trustico.
Unfortunately, the email was not sent to the appropriate certificate problem
reporting channels and did not surface immediately so we're delayed in
sharing the concerns and information. Once we were alerted, the team kicked
off a debate that I wanted to bring to the CAB Forum. Basically, our
position is that resellers do not constitute subscribers under the Baseline
Requirement's definitions (Section 1.6.1). As such, we needed to confirm
that either the key was compromised or that they revocation was authorized
by the domain holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.

 

I think there's a little nuance to this in the general case (e.g. consider 
"Resllers" who are also the hosting provider, and thus constitute the 
Applicant/Subscriber even when they're not the domain holder, but authorized by 
them), but based on this specific case, I think this sounds like a correct 
determination.

 

I think the biggest question is who agreed to the terms - Trustico or the 
end-user - and that mostly impacts the rest of the decision here. Further, did 
Trustico warrant on behalf of the user that the user agreed to the terms (in 
which case, I would think it's a bit of a copout, and it's really Trustico 
agreeing, thus the Subscriber), or did DigiCert have direct communication with 
the user on the basis of Trustico's introduction (in which case, yeah, the 
Subscriber is the user)

 

Anyway, just highlighting it here as perhaps not a uniform consensus, but 
perhaps not as material as what follows.

 

On 2/27/2018, at my request for proof of compromise, we received a file with
23k private keys matched to specific Trustico customers. This definitely
triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
Once we received the keys, we confirmed that these were indeed the matching
private keys for the reported certificates. We will be revoking these
certificates today (February 28th, 2018).

 

I think all of this sounds reasonable, no different than a security researcher 
(or random member of the public) who were to claim compromise with no evidence 
of that.

 

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.

 

For the same reason that "Jane Random User" should not be able to cause 
revocation merely by assertion, I think that sounds reasonable.

 

This raises a question about the MDSP policy and CAB Forum requirements. Who
is the subscriber in the reseller relation?  We believe this to be the key
holder. However, the language is unclear. I think we followed the letter and
spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot
that clarifies the subscriber in a reseller relationship.

 

I think the question here is less about who is the Applicant, but who is the 
Applicant Representative. If the Reseller is signing/agreeing the request on 
beha

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

The keys were emailed to me. I'm trying to get a project together where we
self-sign a cert with each of the keys and publish them. That way there's
evidence to the community of the compromise without simply listing 23k
private keys. Someone on Reddit suggested that, which I really appreciated.
I think the main hold up in this plan is, which websites do we want to call
out? 

-Original Message-
From: dev-security-policy

On Behalf Of Peter Bowen via dev-security-policy
Sent: Wednesday, February 28, 2018 12:38 PM
To: Wayne Thayer 
Cc: timx84...@gmail.com; mozilla-dev-security-policy

Subject: Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 11:29 AM, Wayne Thayer via dev-security-policy
 wrote:
> On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy
 wrote:
>
>>
>> Regarding to our investigation they were only able to send the 
>> private keys for those certificates where the CSR / private key pair 
>> were generated within their online private key generating tool. This 
>> has to be the 23k amount of keys which Jeremy received.
>>
>> I am not aware of guidelines of the CA/B forum but keeping 23.000 (!) 
>> private keys at your online platform seems more than alarming and is 
>> careless and the public should be made aware of this fact.
>>
> I agree with this sentiment, but I also think it creates another 
> policy question with respect to DigiCert's decision to revoke due to 
> key
> compromise: were these 23,000 keys really compromised? The BR 
> definition of Key Compromise is:
>
> A Private Key is said to be compromised if its value has been 
> disclosed to an unauthorized person, an unauthorized person has had 
> access to it, or there exists a practical technique by which an 
> unauthorized person may discover its value. A Private Key is also 
> considered compromised if methods have been developed that can easily 
> calculate it based on the Public Key (such as a Debian weak key, see 
> http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
> specific method used to generate the Private Key was flawed.
>
> In this case it might be reasonable to argue that Trustico was 
> unauthorized (unless their customers agreed to key escrow when using 
> the online key generation tool). However, in the case of a hosting 
> provider reselling certificates for use on their platform, it's 
> required that they hold the private key and we don't consider that a Key
Compromise.

Jeremy's email suggests that the keys were emailed to him.  If this is
accurate, then it is reasonable that they have been "disclosed to an
unauthorized person".  The only other alternative, again assuming Jeremy did
receive the keys, is to determine that he was authorized by the subscriber
to access the keys.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

We don't have a process to prevent third parties from storing private keys.
I'm not sure how that would even work considering the approved third-party
use cases vs. non-approved use cases.  In fact, I'd postulate there's
nothing wrong with Trustico holding the private keys if they were hosting
the site or providing CDN services for all of these sites. The issue is
Trustico alleged compromise of the certificates and sent us the private keys
believed compromised in support. There were a lot of them. 

This is a mass revocation without any explanation of what went wrong or why.
The reseller mentioned and proved compromise, but there's no way to see if
what happened, whether the issue was mitigated, or how it's going to be
prevented from happening again. Basically, we're revoking 50k people without
being able to explain why (well, other than the key was compromised). 

-Original Message-
From: dev-security-policy

On Behalf Of urijah--- via dev-security-policy
Sent: Wednesday, February 28, 2018 2:24 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

Is Trustico's storage of private keys related to this security report from a
few months back (which did not appear to ever have been fully
investigated...)?

https://clicktime.symantec.com/a/1/gUJtIwxyRazHoxd9FIcS40cx3EykeGjrwv4urOpHj
u0=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D
eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH
G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB
Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP
1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui
OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg-
cER_Pj3TmyKGPFFw_SzUky&u=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla
.dev.security.policy%2FCEww8w9q2zE%2FF_bzX1guCQAJ

Does Digicert have (or will it have) some sort of process in place to
prevent resellers from storing private keys so casually?

On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote:
> Hi everyone,
> 
>  
> 
> I wanted to share an incident report regarding the revocation of 
> certain certificates ordered through a reseller.
> 
>  
> 
> On February 2nd, 2018, we received a request from Trustico to mass 
> revoke all certificates that had been ordered by end users through
Trustico.
> Unfortunately, the email was not sent to the appropriate certificate 
> problem reporting channels and did not surface immediately so we're 
> delayed in sharing the concerns and information. Once we were alerted, 
> the team kicked off a debate that I wanted to bring to the CAB Forum. 
> Basically, our position is that resellers do not constitute 
> subscribers under the Baseline Requirement's definitions (Section 
> 1.6.1). As such, we needed to confirm that either the key was 
> compromised or that they revocation was authorized by the domain 
> holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.
> 
>  
> 
> Later, the company shared with us that they held the private keys and 
> the certificates were compromised, trying to trigger the BR's 24-hour 
> revocation requirement.  However, we insisted that the subscriber must 
> confirm the revocation request or there must be evidence of the private
key compromise.
> 
>  
> 
> Normally, we permit partners to revoke and manage the certificates 
> freely on behalf of their customer, with DigiCert providing all 
> validation and issuance services. However, the sheer number of 
> revocation requests (50k) and allegation of compromise triggered 
> concerns around the impact to the web and browser users. Therefore, 
> this was categorized as high risk, especially considering the relationship
between Trustico and DigiCert is terminating.
> 
>  
> 
> On 2/27/2018, at my request for proof of compromise, we received a 
> file with 23k private keys matched to specific Trustico customers. 
> This definitely triggered our 24-hour revocation processing requirement
under 4.9.1.1.3.
> Once we received the keys, we confirmed that these were indeed the 
> matching private keys for the reported certificates. We will be 
> revoking these certificates today (February 28th, 2018).
> 
>  
> 
> At this time, Trustico has not provided any information about how 
> these certificates were compromised or how they acquired the private 
> keys. As is standard practice for a Certificate Authority, DigiCert 
> never had possession of these private keys.
> 
>  
> 
> Currently, we are only revoking the certificates if we received the 
> private keys. There are additional certificates the reseller requested 
> to have revoked, but DigiCert has decided to disregard that request 
> until we receive proof of compromise or more information about the cause
of this incident.
> 
>  
> 
> DigiCert sent out emails to 

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

Yep - that was you. Thanks a ton. We posted 10 CSRs so far. Is this what you
were thinking? 

-Original Message-
From: Nick Lamb  
Sent: Wednesday, February 28, 2018 2:37 PM
To: dev-security-policy@lists.mozilla.org
Cc: Jeremy Rowley 
Subject: Re: How do you handle mass revocation requests?

On Wed, 28 Feb 2018 20:03:51 +
Jeremy Rowley via dev-security-policy
 wrote:

> The keys were emailed to me. I'm trying to get a project together 
> where we self-sign a cert with each of the keys and publish them.
> That way there's evidence to the community of the compromise without 
> simply listing 23k private keys. Someone on Reddit suggested that, 
> which I really appreciated.

That's probably me (tialaramex).

Anyway, if it is me you're referring to, I suggested using the private keys
to issue a bogus CSR. CSRs are signed, proving that whoever made them had
the corresponding private key but they avoid the confusion that comes from
DigiCert (or its employees) issuing bogus certs.
Everybody reading m.d.s.policy can still see that a self-signed cert is
harmless and not an attack, but it may be harder to explain in a soundbite.
Maybe more technically able contributors disagree ?


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Fwd: [cabfpub] How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

Posted to cab forum accidentally instead of Mozilla dev


Begin forwarded message:

From: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>
Date: February 28, 2018 at 2:33:41 PM MST
To: Ryan Sleevi mailto:sle...@google.com>>, Geoff Keating 
mailto:geo...@apple.com>>
Cc: CA/Browser Forum Public Discussion List 
mailto:pub...@cabforum.org>>
Subject: RE: [cabfpub] How do you handle mass revocation requests?

Here’s 10 CSRs that people can correlate with the CT logs. I’ll create another 
100 or so to dispel any doubt.

-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMamagziY67jAV1XWBT2UBudz8leqPeZ
nMGCP9Sct2qc5tDDLz34QIMFO9mv4eDRduMOTG7rwQygKPvI0mAKzKDJCxUvKLYJ
Th/IALgkHfSvv7UzXUxF2kxviuvTCoP0Oee3DUJl4V614R2BnEtEpjEC4WNZglIU
ytQiX36u4WQEbU1LGxp16+Rqz55TOnqRaUNlCCVjB99A3dvxYxpa+6qUHt2aeEyW
WBguBq4sDzOeeLCcnfiCywbDKD4YeqQxvn1EJGBrCQnOf5UdHidJB3ZKKngYWKaZ
48nYK2CqM1dq44vIH6EezGq+0Xs8EFJfi2mjDghfziiX1UtpUt2/vUcCAwEAAaAA
MA0GCSqGSIb3DQEBCwUAA4IBAQA/HM907Hc/rV+olpHW8n1N0UkhfbVHjSegFhQZ
2Wn4jFKAargvOCGDChThcnUbquptKpTFVaKJap0JB2T+fCI3WAMPG8CJKakcOjG/
ZKheN3fNGUiaNk/Wyh/f6XnhWbchIK2OpcsSUAA5ju14bqs2epWl17c0MBPVY5sJ
wFIBrNVjqji3Zkf7aE9GSMx36d8swfhqwomvFvO5SGKspPm2eRpBPwi8lRORDxz3
cAoG4TU3/7xs2XAyTE27UQwdrUo7jkVUlCFoWf6DySHEy7CKTz3Vwu9ABtNdBtG9
oEnWxhIhBPcYOwCrGkiJGuRImFAfLifHWvLUNqGKpz/nEr+c
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEcMBoGA1UECxMTUHJvb2Ygb2Yg
Y29tcHJvbWlzZTEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqS0TSQbsGiJdAYfhuNrGzvXX4XvwToLBq+Hx
trxKq8zoWIRtimRuH66uRmVy0I/lR78u4FEewAjblaS+v1jTLNopik+taBiFHudn
/RGliOcKFohp4BYZuSZRRt3uLN5z8Jr5VbRMzZy6SNp3wX3f+Ie/XsAV04TXmbSv
+V8ZUjxzj1448DsCFL1NNDUcoic/MUcW+fsu9VuxhdETOwrf7CgJ91FgzwHHSMKL
Mq6DwY6xF90KQ5vInhYhRQ447zoSW1ABnmF+gPxDjXXb5pCh4aua8wOv3AmiZbbn
Nnkv9y1YXIeBJ1o1zbTt51v62Qu4LeRYVfWjhI1sn8k96DH8mQIDAQABoAAwDQYJ
KoZIhvcNAQELBQADggEBADgA4tGSyIpAA9uXooQivo9NH7lZH+M4bXpn+nOmNxn/
aRzmbg9NksRKrQoN0/CkWpiu6vwp31gAG2eIpnvNX9ltzPD2/yHAQCLUZmiGZnUP
fUdV1t7Z1EZ9Mj7YmlAN5NuQPAu7SL5fZ8UJSzzY1H7AuECU29j81dK2jLxRR1p6
PaajUGPAvraVTZND4JGQJpIazrF+mVDADdt1aOntr6lj+CC92E5oQxCWtU8uUX7Y
k5OJdewmNlVIk7wtcuVA2ju3jFlNtHP66DE/UDlcx5X5vE2qFq3aZFAqUAf0XXWW
bagqqjxfHSQaNVGlWBkJb0eCdD+DW8IK0nuw5GP2rzY=
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfZnCmYERBmZPEMdK5yvvC0QXjB1FQo
bu4IC9W1ThdFySkJL6t2MeoxbaTW8hwdATf8JHlRnrpevXStUsYDZShxpsQePZk8
LUW5OHQ6W/XDbGo4tC69Q3XTYvLeX+3q971mbiyFpBondTKZaKZYAR5omV7e/Olt
ZzN1yqyX551NsSwDGTrgBqCU2XQzYu9Tl9Nibjl4yCKCG9/JbgGa+gy8j1eKWxIt
lW7jmJID8s0N2v0ed1lvxr7A3oCiYef4TSi2RjLyZThGw1a7j3QqlBeGIqo89XtG
8GxA2nNSGx7gnIceMGGUd0q9iGQl1gc+FOI5oBbyjLcMCty2YInMQucCAwEAAaAA
MA0GCSqGSIb3DQEBCwUAA4IBAQBQyDCiBYXRMOryHhVVW52kY6wvsgWsPXLR0piQ
FJKP/drPdqgs/uxY6Nx163sNaiWPEI0tUWSmnuPe43qAyIqJXmnd/C6EqGy+ZI1Y
lf0XAfqVzJ+tc9639pSkGfeGxU75qdPwWqbwzEEdNZCDR/4QqzhGgMLyvH7icoc0
7ikxxwyUiKpP4h3nAV7Fg4EMKeEn/3m+vM0aGnZNx16WHpQF/VnyBM8NimADmO/u
vywC2TbLNBYYYG7dlLUk7fYfoFY5okel4z2fjmaNhuQQEpffJ366DC41A3fWDgp8
j1Ok8PfhiVySEwdSCNgpZbHnSwxodk4E3aZ22kCa2f7nOzDd
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBALjEWXaHdMifi0LbL0GrnYV6uoltTicU
ywDOkSz/cReCI6gzxb1jpuQu1iVAkmiZUmPk4sPjc4e/OvAo0IyXgVEqBVcB4cmB
JTdWFj4fde8G9/NWoKIHIRVS4envx4jjRFEh6uDI9o4pDcpfvjh59s1RCjqU9EqX
DueUoKCk7eynjBxePNYZtZL5xBbBRIeqkjtBALtdnQdkbMTBAHJT4WvK2y9ExtWY
aJAoAf0ZYmQOeqzXZC4w1FKs7/GEa1qaPjyxe596LvZvOMZbB49gUYou6lhmG+ga
PaJIGm53/A4PgLnCisEjrVL46YB/k/EzTQtwq5jRg5usIL0/YCJlvCkCAwEAAaAA
MA0GCSqGSIb3DQEBCwUAA4IBAQCgCziprbbD+aS22QHBMOnjy5r7iYiteKO1uB1o
zdaKpNBg32+tNyYsNazijAb0rcyFLGAeTfjbWQ5YDbK44qGmKxhO5nyeUkb9/ulI
scT94Trwu8j77DTxaFNTziETbw5KIBfiC7M5cD+vQ2UexJ8giv9s7ZchXY/hK8TA
IPY1jfEzioEgjap2bXhZ7GGHhjNg/3DIHCy2dD+eDeTsHhZQ+4ndfMeydg9fn6se
20A73X5rFGYKtp3z19stTDjXFDVyf/ngXtyti830ebQgmxRLJRAKV+MSHrdxW4Jj
qkuW6fmTj2s3x8iTKecd5Q/NOKt2XjOMldc6eKA4VSi3QNuc
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBALlY3wwEZcO3U4HGuYE6atvaG3vOiOGq
y1W1Nwv4xVCiVkTECgbumYZyBjq1XxVKC1dNJ2nzxDSIhPNxnJZHA7v5SvSf60+Z
1W+Q

Re: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

No. Just the 23k. Part of the reason I posted to the Mozilla list are open 
questions about whether Trusticos request is sufficient to trigger the br 
requirements. My gut is no, and sounds like the browsers agree.  We’ll only 
revoke the remaining 27k if we receive evidence of compromise

On Feb 28, 2018, at 2:52 PM, jomo 
mailto:mozilla-li...@jomo.tv>> wrote:


Basically, we're revoking 50k people without
being able to explain why (well, other than the key was compromised).

Unless I misunderstood, you originally said you received 23k compromised keys 
and are revoking those.

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.


Has DigiCert received proof of compromise of all 50k in the meantime?


On 28.2.18 22:42, Jeremy Rowley via dev-security-policy wrote:

We don't have a process to prevent third parties from storing private keys.
I'm not sure how that would even work considering the approved third-party
use cases vs. non-approved use cases.  In fact, I'd postulate there's
nothing wrong with Trustico holding the private keys if they were hosting
the site or providing CDN services for all of these sites. The issue is
Trustico alleged compromise of the certificates and sent us the private keys
believed compromised in support. There were a lot of them.

This is a mass revocation without any explanation of what went wrong or why.
The reseller mentioned and proved compromise, but there's no way to see if
what happened, whether the issue was mitigated, or how it's going to be
prevented from happening again. Basically, we're revoking 50k people without
being able to explain why (well, other than the key was compromised).

-Original Message-
From: dev-security-policy
<mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org>
On Behalf Of urijah--- via dev-security-policy
Sent: Wednesday, February 28, 2018 2:24 PM
To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: How do you handle mass revocation requests?

Is Trustico's storage of private keys related to this security report from a
few months back (which did not appear to ever have been fully
investigated...)?

https://clicktime.symantec.com/a/1/gUJtIwxyRazHoxd9FIcS40cx3EykeGjrwv4urOpHj
u0=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D
eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH
G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB
Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP
1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui
OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg-
cER_Pj3TmyKGPFFw_SzUky&u=https%3A%2F%2Fgroups.google.com<http://2Fgroups.google.com>%2Fd%2Fmsg%2Fmozilla
.dev.security.policy%2FCEww8w9q2zE%2FF_bzX1guCQAJ

Does Digicert have (or will it have) some sort of process in place to
prevent resellers from storing private keys so casually?

On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote:


Hi everyone,



I wanted to share an incident report regarding the revocation of
certain certificates ordered through a reseller.



On February 2nd, 2018, we received a request from Trustico to mass
revoke all certificates that had been ordered by end users through


Trustico.


Unfortunately, the email was not sent to the appropriate certificate
problem reporting channels and did not surface immediately so we're
delayed in sharing the concerns and information. Once we were alerted,
the team kicked off a debate that I wanted to bring to the CAB Forum.
Basically, our position is that resellers do not constitute
subscribers under the Baseline Requirement's definitions (Section
1.6.1). As such, we needed to confirm that either the key was
compromised or that they revocation was authorized by the domain
holder (the subscriber) prior to revoking the certificate. The


certificates were not alleged as compromised at that time.




Later, the company shared with us that they held the private keys and
the certificates were compromised, trying to trigger the BR's 24-hour
revocation requirement.  However, we insisted that the subscriber must
confirm the revocation request or there must be evidence of the private


key compromise.




Normally, we permit partners to revoke and manage the certificates
freely on behalf of their customer, with DigiCert providing all
validation and issuance services. However, the sheer number of
revocation requests (50k) and allegation of compromise triggered
concerns around the impact to the web and browser user

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

1) Not all of the certificates being revoked use the Symantec hierarchy.
There are some certs that use the DigiCert replacement hierarchy. Not many
though.
2) Sorry my wording was strange.  It almost always is.  What I meant, is
Trustico specifically asked for the certs to be revoked within 24 hours as
required by the BRs. They said in the email they were triggering the 24 hour
requirement. 
3) I really feel like a third point would be important, but I can't think of
one. 

-Original Message-
From: dev-security-policy

On Behalf Of Matthew Hardeman via dev-security-policy
Sent: Wednesday, February 28, 2018 3:23 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 3:55:37 PM UTC-6, Ryan Duff wrote:
> >From what I've read, it appears the situation here is that Trustico
wanted to revoke all their customer certs from Digicert so they could do a
mass migration to another CA (which is not a proper reason to revoke). When
asked for proof by Digicert that the certificates were compromised and
needed to be revoked, Trustico sent Digicert 23,000(!) private keys that
*they had stored* due to the fact that they were generated by their
web-based system in order to effectively *make them* compromised.
> 
> Am I missing anything?

That's kind of what I was thinking happened also.

Though a couple points to correct:  The original issuing CA hierarchy is a
Symantec trust path.  This suggests that what they really wanted to occur
was to trigger a 24 hour reissue of all of these certificates under a
DigiCert trusted path -- since presumably any issuance at this point would
fall under a DigiCert path.

Thus, within 24 hours, getting new certificates for all their customers
under the new trust path.  I'm going to guess someone at Trustico was
getting annoyed at support calls regarding the migration and somehow assumed
there'd be no consequences for pushing the issue by way of getting all those
certificates revoked on "security" grounds.

As grounds for this belief, I submit the strangely worded statement of Mr.
Rowley at the start of the thread "Later, the company shared with us that
they held the private keys and the certificates were compromised, trying to
trigger the BR's 24-hour revocation requirement".

That language seems to imply that there's a sense that the security / web
PKI integrity aspect is less the matter at stake and more that the keys were
located and sent over to create an impossible to ignore security issue
forcing the 24 hour window.

My guess is that the person at Trustico wanted immediate reissuance of all
of the Symantec certificates under the DigiCert trust paths and assumed:

1.  That revoking the certs for security reasons would result in ASAP
reissue (probably true in one-offs).
2.  That the reissuance would happen in the DigiCert trust path (almost
certainly true).
3.  That they'd have a spike of support issues related to the reissuances,
but that Trustico would have more control over the period over which they
had to help customers migrate certificates and then the "bleeding" would
stop.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/1SicdYM5NOSV8S29ZlemtDgUftWWe-mEnCeFfDCfA
lw=?d=paMnJZlER7IHb626K-31V2u-Kf4DBs2hoO7Bro78ZuywH3EZ9N1dve7JXTCFPZFHyQrvw7
cDEqjPm1CCO0iQqqCbe-J7q2_uVOXTQzSslJpmeaUe9RmpgB81xaobKJOyb_YpAY8IOdkE832w7N
tu7J94BmAMUFyIN-LINYJhcdKrmRggiP3dwENTjoH8GFBgeJgbAAJ7AXEY8EsaOLt-dqVymUiml9
GCqK8Pz2bZYq21i2TjrlH5i5ctTnHGcaJLrBukwohzJ1XA0B0Ma6sfh6NdDO9yi3psZCXUIDcZyp
5FtLBoYtTo6DUQVC8VhfOJY6KGhSpursgUnQdy6yQRtirjLO9kmIOKJSuJvlbaKD3gYKkxIRzMLA
6jPbVCxU77Z6q6OAnzLtAIRiCe7-MVzty2jFdcG8R9uiVI7Vf241-3ANcBFbr288JrDaZYHwhYJu
rWo3wUC3HNJXFV_nf74MJE&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-se
curity-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

Thanks Alex. Sorry for the delayed response. I've been traveling today.
We're reaching out to each of the customers and getting their cert replaced.


Looking into this, we did not correctly implement the ballot:
1. We didn't add a check to our backend system too verify the cert included
a descriptor prior to issuance. 
2. On the front end, we missed requiring a Tor descriptor prior to
processing the order. 
3. The validation team received insufficient training on the Tor descriptor
requirement. 

In reality, the issue was too much reliance on the human component of
asserting the Tor descriptors instead of having a technical control in
place. We're working on putting those technical controls in place.  

Jeremy

-Original Message-
From: dev-security-policy

On Behalf Of Alex Cohn via dev-security-policy
Sent: Sunday, March 11, 2018 9:37 PM
To: dev-security-policy@lists.mozilla.org
Subject: DigiCert .onion certificates without Tor Service Descriptor Hash
extension

In the EV Guidelines [1], Appendix F states "The CA MUST include the CAB
Forum Tor Service Descriptor Hash extension in the TBSCertificate convey
hashes of keys related to .onion addresses." This language was added in
Ballot 201 [2], which had an effective date of 8 July 2017.

The following certificates (and precertificates if the corresponding
certificate is not in a public CT log) were issued by DigiCert after 8 July
for .onion domains, but lack the necessary extension:
https://crt.sh/?q=240277340 (revoked 26 October 2017)
https://crt.sh/?q=261570255
https://crt.sh/?q=261570338
https://crt.sh/?q=261570380
https://crt.sh/?q=261570384
https://crt.sh/?q=261579788
https://crt.sh/?q=261601212
https://crt.sh/?q=261601280
https://crt.sh/?q=261601281
https://crt.sh/?q=261601284
https://crt.sh/?q=261988060
https://crt.sh/?q=326491168
https://crt.sh/?q=326830043
https://crt.sh/?q=328308725
https://crt.sh/?q=328961187
https://crt.sh/?q=329559222
https://crt.sh/?q=330180704
https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email to
DigiCert)

This was previously discussed on m.d.s.p about a year ago [3].

[1]
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.
8.pdf
[2] https://cabforum.org/2017/06/08/2427/
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNI
D_xfAgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla Security Blog re Symantec TLS Certs

[Jeremy Rowley via dev-security-policy]

Same question. Does this mean the key used to sign the digicert roots is 
subject to the distrust without exception?

> On Mar 13, 2018, at 1:36 PM, Kai Engert via dev-security-policy 
>  wrote:
> 
>> On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
>> Wayne and I have posted a Mozilla Security Blog regarding the current
>> plan for distrusting the Symantec TLS certs.
>> 
>> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/
> 
> Hello Kathleen and Wayne,
> 
> the blog post says, the subCAs controlled by Apple and Google are the
> ONLY exceptions.
> 
> However, the Mozilla Firefox code also treats certain DigiCert subCAs as
> exceptions.
> 
> Based on Ryan Sleevi's recent comments on this list, I had concluded
> that the excluded DigiCert subCAs are used to support companies other
> than Apple and Google. Is my understanding right or wrong?
> 
> Are Apple and Google really the only beneficials of the exceptions, or
> should the blog post get updated to mention the additional exceptions?
> 
> Thanks
> Kai
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

Interesting - this escaped our notice because it has a Tor descriptor. 
Unfortunately, it looks like the fetch function with v3 is not supported so 
we'll have to change how we pull and include the descriptor. Since the key is 
already in the cert, I agree there is nothing gain by including it, but I 
doubt there's strong incentives to change the guidelines right now. We'll 
modify to include it.

-Original Message-
From: Alex Cohn 
Sent: Monday, March 12, 2018 6:55 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert .onion certificates without Tor Service Descriptor Hash 
extension

Thanks, Jeremy.

I also found a certificate [1] with both 16-character.onion and 
56-character.onion addresses [2] listed in the SAN. The v3 address is not 
included in the 2.23.140.1.31 extension, which seems to violate the same rule 
as below. However, v3 addresses include the service's entire public key in the 
address itself, so there's nothing to be gained by embedding a hash of that 
key in a certificate.

I'm not sure what, if anything, needs to happen in this case. Thoughts?

Alex

[1] https://crt.sh/?id=351449246
[2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt

On Mon, Mar 12, 2018 at 7:28 PM, Jeremy Rowley via dev-security-policy 
 wrote:
> Thanks Alex. Sorry for the delayed response. I've been traveling today.
> We're reaching out to each of the customers and getting their cert replaced.
>
>
> Looking into this, we did not correctly implement the ballot:
> 1. We didn't add a check to our backend system too verify the cert
> included a descriptor prior to issuance.
> 2. On the front end, we missed requiring a Tor descriptor prior to
> processing the order.
> 3. The validation team received insufficient training on the Tor
> descriptor requirement.
>
> In reality, the issue was too much reliance on the human component of
> asserting the Tor descriptors instead of having a technical control in
> place. We're working on putting those technical controls in place.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy
>  org> On Behalf Of Alex Cohn via dev-security-policy
> Sent: Sunday, March 11, 2018 9:37 PM
> To: dev-security-policy@lists.mozilla.org
> Subject: DigiCert .onion certificates without Tor Service Descriptor
> Hash extension
>
> In the EV Guidelines [1], Appendix F states "The CA MUST include the
> CAB Forum Tor Service Descriptor Hash extension in the TBSCertificate
> convey hashes of keys related to .onion addresses." This language was
> added in Ballot 201 [2], which had an effective date of 8 July 2017.
>
> The following certificates (and precertificates if the corresponding
> certificate is not in a public CT log) were issued by DigiCert after 8
> July for .onion domains, but lack the necessary extension:
> https://crt.sh/?q=240277340 (revoked 26 October 2017)
> https://crt.sh/?q=261570255
> https://crt.sh/?q=261570338
> https://crt.sh/?q=261570380
> https://crt.sh/?q=261570384
> https://crt.sh/?q=261579788
> https://crt.sh/?q=261601212
> https://crt.sh/?q=261601280
> https://crt.sh/?q=261601281
> https://crt.sh/?q=261601284
> https://crt.sh/?q=261988060
> https://crt.sh/?q=326491168
> https://crt.sh/?q=326830043
> https://crt.sh/?q=328308725
> https://crt.sh/?q=328961187
> https://crt.sh/?q=329559222
> https://crt.sh/?q=330180704
> https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email
> to
> DigiCert)
>
> This was previously discussed on m.d.s.p about a year ago [3].
>
> [1]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.
> 8.pdf
> [2] https://cabforum.org/2017/06/08/2427/
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNt
> s/ZtNI
> D_xfAgAJ
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

True. I can tell you our process was not followed in this case, primarily 
because of the Symantec transaction.



Ideally, when we add new products (or when a CAB Forum requirement changes), 
we:

1.  Add the mandatory criteria to our compliance engine
2.  Add the new cert to our issuing CA
3.  Add the validation requirements in validation service
4.  Train the staff on the new product/service
5.  Enable access via the API and GUI



For the most part compliance takes place in two areas (in our updated system). 
First in the compliance engine for all things technical. Second in the 
validation service for all validation requirements. On the onion cert issue, 
we only did #2 and #4.



From: dev-security-policy 
 On 
Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, March 22, 2018 9:31 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert .onion certificates without Tor Service Descriptor Hash 
extension



On 21 Mar 2018 17:58, Wayne Thayer via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

7.  List of steps your CA is taking to resolve the situation and
ensure such issuance will not be repeated in the future, accompanied
with a timeline of when your CA expects to accomplish these things.

We revoked the certificates and added preliminary checking for Tor
descriptors. We are adding additional checks to ensure certs cannot
issue without them.



A broader consideration might be how DigiCert (or any CA) can ensure such 
checks get thought up / planned for during the process of spinning up a new 
type of issuance.

Imagine the CA/B eventually authorizes some hypothetical new "MV" 
certificates, they are Web PKI certs but with some different (less / more / 
just strange) validation and criteria for the cert itself. Obviously we cannot 
plan today for how this should be done exactly, but a CA thinking of issuing 
MV ought to - as part of that - figure out what needs to happen in terms of 
preventing mis-issuance of the new certs.

Otherwise we're inevitably back here shortly after the CA/B says OK.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Jeremy Rowley via dev-security-policy]

If you don't specify by EKU, the exercise of determining intent becomes
impossible as illustrated by our (many) attempts to define a server cert in
CAB Forum. Better to list the EKUs allowed and not allowed in the same cert
than rely on another intent requirement. 

-Original Message-
From: dev-security-policy

On Behalf Of Doug Beattie via dev-security-policy
Sent: Tuesday, April 17, 2018 1:37 PM
To: Wayne Thayer ; mozilla-dev-security-policy

Subject: RE: Policy 2.6 Proposal: Require separate intermediates for
different usages (e.g. server auth, S/MIME)



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, April 17, 2018 2:24 PM
> To: mozilla-dev-security-policy  pol...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Require separate intermediates for 
> different usages (e.g. server auth, S/MIME)
> 
> This proposal is to require intermediate certificates to be dedicated 
> to specific purposes by EKU. Beginning at some future date, all newly 
> created intermediate certificates containing either the 
> id-kp-serverAuth or id-kp- emailProtection EKUs would be required to
contain only a single EKU.

We'll need to support a list of EKUs if this becomes a requirement.  Server
Auth certificates should be able to support lots of different EKUs, for
example: 
id-kp-serverAuth
id-kp-clientAuth
id-kp-ipsecEndSystem
id-kp-ipsecTunnel
id-kp-ipsecUser
KDC Authentication
Smart Card Logon
iPSec IKE
IKE Intermediate

> Arguments for this requirement are that it reduces risk of an incident 
> in which one type of certificate affecting another type, and it could 
> allow some policies to be restricted to specific types of certificates.
> 
> It was pointed out that Microsoft already requires dedicated 
> intermediates [1].

I agree with using dedicated intermediates, but I'd prefer that they should
not be required to be EKU constrained.

> I would appreciate everyone's input on this topic.
> 
> I suspect that it will be tempting to extend this discussion into 
> intermediate rollover policies, but I would remind everyone of the 
> prior inconclusive discussion on that topic [2].
> 
> This is: https://github.com/mozilla/pkipolicy/issues/26
> 
> [1] https://aka.ms/rootcert
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-
> TQ8/hgVsCofcAgAJ
> ---
> 
> This is a proposed update to Mozilla's root store policy for version 2.6.
> Please keep discussion in this group rather than on GitHub. Silence is
consent.
> 
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Policy 2.6 Proposal: Require CAs to support problem reports via email

[Jeremy Rowley via dev-security-policy]

I believe the intent of the certificate problem reporting in the BRs is to 
encourage CAs to accept and respond to issues. Although the intent is not 
specifically stated, my reasoning is based on the fact the BRs requiring CAs to 
maintain a 24x7 ability to respond, a 24 hour ability to process certificate 
problems, and a public reporting mechanism. To support this objective, I think 
we should make the process as easy as possible for reporters, including 
mandating email. Finding the email addresses is a pain with little reward. 
Having to go through captchas to even get the email sent is just another 
obstacle in getting the CA a timely certificate problem report.  Therefore, I'd 
adopt Ryan Hurst's proposal and require that the email be in a standardized 
format (no more hunting for email aliases) without any blockers to prevent the 
certificate problem report. Filtering through the mess of emails you get on 
those aliases is the CAs responsibility. 

Jeremy

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Tuesday, April 17, 2018 10:50 AM
To: mozilla-dev-security-policy 
Subject: Policy 2.6 Proposal: Require CAs to support problem reports via email

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says:
"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 types of fraud, 
compromise, misuse, inappropriate conduct, or any other matter related to 
Certificates. The CA SHALL publicly disclose the instructions through a readily 
accessible online means.”

Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it 
turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. 
It is proposed that Mozilla policy go above and beyond the BR requirement to 
state that email must be one of the problem reporting methods supported.

Another argument in favor or requiring CAs to accept problem reports via email 
is that it provides the reporter with evidence of the submission via their 
email client and server logs.

Arguments against this requirement include the burden placed on CAs who must 
sort through the large quantities of SPAM received by any published email 
address, concerns with email reliability, and the reporter's inability to 
confirm that their email has been received by the CA.

According to CCADB [1], all but a handful of CAs already support problem 
reporting via email.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/98

[1]
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
---

This is a proposed update to Mozilla's root store policy for version 2.6. 
Please keep discussion in this group rather than on GitHub. Silence is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RAs and the BRs

[Jeremy Rowley via dev-security-policy]

There is a way to get zero-validation certs, totally legit, under the BRs.
Currently, the BRs permit pretty much free delegation of Registration
Authorities for everything except domain verification. Without RA audit
requirements or even a requirement that the CA monitor/control the RA, the
cynical-side of me doubts whether the verification is enforced without the
CA first receiving a third-party complaint. Section 1.32 permits free RA
delegation if the verification requirements are met by the process as a
whole and that a contract exist between the delegated third party to do the
following:"(1) Meet the qualification requirements of Section 5.3.1, when
applicable to the delegated function; (2) Retain documentation in accordance
with Section 5.5.2; (3) Abide by the other provisions of these Requirements
that are applicable to the delegated function; and (4) Comply with (a) the
CA's Certificate Policy/Certification Practice Statement or (b) the
Delegated Third Party's practice statement that the CA has verified complies
with these Requirements.". Essentially, as long as there is a) a contract
between the CA and RA, and b) the CA is performing domain verification (and
c) no one complains), the RA is free to do whatever the RA deems
appropriate, permitting the CA to circumvent the BRs and audit oversight.
There's no requirement that the CA audit the RA's role in the verification
process or that the RA provide any reporting to the CA or auditors. 

 

Combined with method 1, there is no obligation the CA actually do anything
to vet the customer or obtain any evidence that the customer even exists.
As you all know, method 1 requires only that the CA confirm the WHOIS
information matches the applicant. As long as the WHOIS information matches,
problem solved. As noted above, the RA is not actually required to do any
validation (just say that they do) so if the RA passes over the WHOIS name
as the verified information, the cert will issue without a second glance.  

 

I realize that method 1 and method 5 are going away (for good reason), but
that doesn't happen until August. I'd be interested in seeing whether
someone can get a cert in this manner from a CA that supports RAs. 

 

Jeremy 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: RAs and the BRs

[Jeremy Rowley via dev-security-policy]

A reasonable control can include contractual controls, thus 6.6 is solved 
simply via contract with the CA. Section 8.7 does give some control (and I 
missed that when going through this the first time), but the audit criteria is 
only that the CA reviews a 3% sample. As long as I documented that I review the 
RA practices and did the 3% review (regardless of the results), then the CA 
escapes oversight on its validation process. 

 

 

From: Wayne Thayer  
Sent: Wednesday, April 18, 2018 1:18 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: RAs and the BRs

 

On Tue, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

There is a way to get zero-validation certs, totally legit, under the BRs.
Currently, the BRs permit pretty much free delegation of Registration
Authorities for everything except domain verification. Without RA audit
requirements or even a requirement that the CA monitor/control the RA, the
cynical-side of me doubts whether the verification is enforced without the
CA first receiving a third-party complaint. Section 1.32 permits free RA
delegation if the verification requirements are met by the process as a
whole and that a contract exist between the delegated third party to do the
following:"(1) Meet the qualification requirements of Section 5.3.1, when
applicable to the delegated function; (2) Retain documentation in accordance
with Section 5.5.2; (3) Abide by the other provisions of these Requirements
that are applicable to the delegated function; and (4) Comply with (a) the
CA's Certificate Policy/Certification Practice Statement or (b) the
Delegated Third Party's practice statement that the CA has verified complies
with these Requirements.". Essentially, as long as there is a) a contract
between the CA and RA, and b) the CA is performing domain verification (and
c) no one complains), the RA is free to do whatever the RA deems
appropriate, permitting the CA to circumvent the BRs and audit oversight.
There's no requirement that the CA audit the RA's role in the verification
process or that the RA provide any reporting to the CA or auditors. 

BR section 1.3.2 defines a Registration Authority as a Delegated Third Party. 
Section 8.7 says:

Except for Delegated Third Parties that undergo an annual audit that meets the 
criteria specified in Section 8.1, the CA SHALL strictly control the service 
quality of Certificates issued or containing information verified by a 
Delegated Third Party by having a Validation Specialist employed by the CA 
perform ongoing quarterly audits against a randomly selected sample of at least 
the greater of one certificate or three percent of the Certificates verified by 
the Delegated Third Party in the period beginning immediately after the last 
sample was taken. The CA SHALL review each Delegated Third Party’s practices 
and procedures to ensure that the Delegated Third Party is in compliance with 
these Requirements and the relevant Certificate Policy and/or Certification 
Practice Statement. 

The CA SHALL internally audit each Delegated Third Party’s compliance with 
these Requirements on an annual basis. 

The WebTrust BR audit criteria include a number of controls related to CA 
oversight of Delegated Third Parties, including 6.6:

 

The CA maintains controls to provide reasonable assurance that the CA 
internally audits each Delegated Third Party’s compliance with the Baseline 
Requirements on an annual basis.



Combined with method 1, there is no obligation the CA actually do anything
to vet the customer or obtain any evidence that the customer even exists.
As you all know, method 1 requires only that the CA confirm the WHOIS
information matches the applicant. As long as the WHOIS information matches,
problem solved. As noted above, the RA is not actually required to do any
validation (just say that they do) so if the RA passes over the WHOIS name
as the verified information, the cert will issue without a second glance.  



I realize that method 1 and method 5 are going away (for good reason), but
that doesn't happen until August. I'd be interested in seeing whether
someone can get a cert in this manner from a CA that supports RAs. 



Jeremy 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Transforming a trade name into ASCII in the O field of an OV cert

[Jeremy Rowley via dev-security-policy]

That is correct. We use transliteration of non-latin names through a system
recognized by ISO per Appendix D(1)(3)

-Original Message-
From: dev-security-policy

On Behalf Of cbonnell--- via dev-security-policy
Sent: Tuesday, April 24, 2018 7:12 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Transforming a trade name into ASCII in the O field of an OV
cert

On Monday, April 23, 2018 at 3:34:38 PM UTC-4, Wayne Thayer wrote:
> Section 9.2.1 of the EVGLs is stricter, only permitting abbreviations. 
> If this were an EV cert I would argue that it was misissued.
> 
> On Mon, Apr 23, 2018 at 12:13 PM, Ryan Sleevi via dev-security-policy 
> < dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Mon, Apr 23, 2018 at 1:11 PM, Henri Sivonen via 
> > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> > > First, it seems to me that the Baseline Requirements allow 
> > > transformations of the organization's name only if the CA 
> > > documents such transformations. I am unable to find such 
> > > documentation in DigiCert's CP and CPS documents. Am I missing
something?
> > >
> >
> > At present, these are not required to be in the public documentation.
> > Merely, the requirement is that the CA "documents" - i.e. it is 
> > presently acceptable to only include this documentation in 
> > information provided to the auditors.
> >
> >
> > > Second, while verifying that the applicant indeed represents a 
> > > specific real organization is a difficult problem, in the case 
> > > where the country that the certificate designates operates an 
> > > online-queryable database of registered businesses, associations, 
> > > etc., it should be entirely feasible to eliminate the failure mode 
> > > where the certificate's organization field is (absent documented 
> > > transformations permitted under the Baseline Requirements) not 
> > > canonically equivalent (in the Unicode sense) to the name of any 
> > > organization registered in the country that the certificates 
> > > designates. That (inferring from the certificate for
> > > www.alandsbanken.fi) there isn't technical process that would by 
> > > necessity remove diacritical marks from the organization field and 
> > > that the certificate for www.saastopankki.fi has them removed is 
> > > strongly suggestive that DigiCert's process for validating 
> > > Finland-based organization does not include as a mandatory part 
> > > either the retrieval of the organization's name via an online API 
> > > to the business registry or a human CA representative copying and 
> > > pasting the organization's name from a browser view to the business
registry.
> > >
> >
> > The Baseline Requirements do not dictate the datasource used in 
> > various jurisdictions. Thus even when there is a canonical source 
> > through legislation, the BRs do not require its use.
> >
> >
> > >  I wonder: When a given country
> >
> > has an online-queryable business registry, why isn't it either
> > > recommended or required to import names digitally from the 
> > > business registry into certificates? Such practice would eliminate 
> > > the failure mode of the certificate designating a name that 
> > > doesn't match any entry in the business registry for such country. 
> > > (Obviously, if it was _required_, the BRs would need to include a 
> > > list of countries whose business registry is considered 
> > > online-queryable in the sense that the requirement would apply, 
> > > but unwillingness to maintain such a list does not explain why it 
> > > isn't even recommended.)
> > >
> >
> > "Recommended" is pointless. Required is the only thing that makes 
> > sense, and the complexities and overhead involved precisely explain 
> > why it isn't required.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://clicktime.symantec.com/a/1/BvQKGKG-atiF6qzY2ACOk9yeXt5fmZNpd
> > -faQX5l0PY=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4d
> > cVTpsXAtxoPHgF9wjrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbN
> > mjtVrSrgW9MjFpB_PV_GA0a6d9CDPW00YSAN5s19pKxQFY4khaGT4tGsNBPV82wJ57B-
> > 0V-gd5e-1RY-WPPfqqiSVefSEHM3CbmoTYvMcDfItqF15BC0QZabSo1qReVcnLtpkA07
> > NalO1afKP9pBC8NHIaF2qytDuUbZ-0_7wZVecDePdhfK4ghowJT_2N6v2KHnCG1cElhU
> > 822SsjxhXhwrQTBMTCLXhqVFTQqZtfPfRLDYzl0PcS-PLbsh2A96Dr_Y2gQ_rxoeIKIc
> > z5ln_0I189aAACvwnBtEFieiU0dIZxR3_s0ZN8Zp7MAS_0DY8i7xp0YGMCEiaC-X0rpJ
> > 5VXKItovyxmoIN7_63_vr5ObrP47_KLALVV-eG2OCX&u=https%3A%2F%2Flists.moz
> > illa.org%2Flistinfo%2Fdev-security-policy
> >

Appendix D of the EV Guidelines
(https://clicktime.symantec.com/a/1/k5LVvsTsn1aOD8kIgUl5TxWF-s1BWAyIy_p_gHjK
8OE=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4dcVTpsXAtxoPHgF9
wjrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbNmjtVrSrgW9MjFpB_PV_GA0a
6d9CDPW00YSAN5s19pKxQFY4khaGT4tGsNBPV82wJ57B-0V-gd5e-1RY-WPPfqqiSVefSEHM3Cbm
oTYvMcDfItqF15BC0QZabSo1qReVcnLtpkA07NalO1afKP9

CT Log deprecation

[Jeremy Rowley via dev-security-policy]

Hi everyone, 

 

I posted our announcement about deprecation of Symantec CT logs over on the
Google list a while ago. I figured I'd post something here as well so the
community is aware of our plans.

 

As part of our infrastructure consolidation DigiCert will be EOLing legacy
Symantec CT log servers listed below at the end of September 2018.

https://ct.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=483625 )

https://vega.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=554549#c18 )

https://sirius.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=692782#c24 )

 

Google seems to operate mirrors for these log servers as announced here
https://www.ietf.org/mail-archive/web/trans/current/msg01485.html 

 

>>> 

- Google is building out log mirrors for all logs included by Chrome,

  and the intent is that read-only requests from Chrome (for STHes, or

  inclusion-proofs (via the DNS mechanism above)) will be serviced by a

  log mirror, rather than the underlying logs.

>>> 

 

These links show the actual mirror for each of above CT Logs:

 
https://ct.grahamedgecombe.com/logs/10

 
https://ct.grahamedgecombe.com/logs/14

 
https://ct.grahamedgecombe.com/logs/31

 

Many CAs apart from DigiCert (legacy Symantec) currently use at least one of
these log servers to log their EV/OV certificates. We strongly recommend
that CAs that currently use any of these log servers should start using any
other log servers in the CT ecosystem as soon as possible (or set up their
log). This will give these CAs enough time to secure permissions (if
required) for using an alternate log server from its operator and complete
integration with it. Legacy Symantec log servers will fully cease to operate
after EOL.

 

If you have specific questions please use the  contact email published with
each log server or contact me.

 

Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Jeremy Rowley via dev-security-policy]

*Some cas. I don’t think the 18 month requirement is a universal position and 
may not even be a majority view.  I think there’s other ideas that are better 
and add more value than simply extending the time a company is required to 
exist to get the cert.

> On May 31, 2018, at 4:40 PM, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> On Thu, May 31, 2018 at 8:39 PM James Burton via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> 
>> This is wrong and should be changed to allow all types of legally
>> incorporated company names to get certificates. I understand this
>> doesn't fit any of the standard company name profiles you've seen but this
>> company name can be used in practice  and I can think of many business
>> types that would love this type of name.
>> 
>> In my opinion, this is just a rehash of the same debate we've been having
> over misleading information in certificates ever since James obtained the
> "Identity Verified" EV certificate. The options we have to address this
> seem to be:
> 1. Accept that some entities, based on somewhat arbitrary rules and
> decisions, can't get OV or EV certs
> 2. Accept that the organization information in certificates will sometimes
> be misleading or at least uninformative
> 3. Decide that organization information in certificates is irrelevant and
> ignore it, or get rid of it
> 
> We currently have chosen "some parts of all of the above" :-)
> 
> I am most interested in exploring the first option since that is the
> direction CAs are headed with the recent proposal to limit EV certificates
> to organizations that have existed for more than 18 months [1]. As long as
> anyone can obtain a DV certificate, are restrictions on who can obtain an
> OV or EV certificate a problem, and if so, why?
> 
> [1] https://cabforum.org/pipermail/validation/2018-May/000882.html
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Disallowed company name

[Jeremy Rowley via dev-security-policy]

Can you point to a jurisdiction that allows you to register the same name? I've 
never seen an example where it's permitted. Maybe the UK?

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Ryan Hurst via dev-security-policy
Sent: Friday, June 1, 2018 9:28 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Disallowed company name

On Thursday, May 31, 2018 at 3:07:36 PM UTC-7, Matthew Hardeman wrote:
> On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> > We can also think of many business types (e.g., scammers) that would 
> > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to 
> > issue certificates with such names. The authorities who approve of 
> > company names don't necessarily have certificate handling in mind...
> >
> 
> Indeed.  Most of the government offices responsible for approving 
> entity creation are concerned first and foremost with ensuring that a 
> unique name within their jurisdiction is chosen and that a public 
> record of the entity creation exists.  They are not concerned with 
> risk management or legitimacy, broadly speaking.
> 
> Anyone at any level of risk management in the rest of the ecosystem 
> around a business will be concerned with such matters.  Banks, trade 
> vendors, etc, tend to reject accounts with names like this.  Perhaps 
> CAs should look upon this similarly.

re: Most of the government offices responsible for approving entity creation 
are concerned first and foremost with ensuring that a unique name within their 
jurisdiction is chosen

What makes you say that, most jurisdictions have no such requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/H8qZVRE5_iLNO8giNWdHECRPUnhWmem4t7fNC9FYfaI=?d=3yPd_yGx1m4dQz3H1uWi0wkNACGDGvIL4Z--LNoP9eDPIWeD0dhf9Ol_tFkJGBJFFgtnLt2HO_UCbFnaqQu3zUWQTHxGduRJO0a_H4yYE3qhYRX3wzvleMJ_cCcflYSP6doSbnmNReFJlR_Gjut8oNV6EnnecC1kzxXkdJG19OPUi3qjxKSp_r4Tlk3ExNNIwR3DF26nn1z6wKDyzP1siUdOGQT4oa70wTAPNZrK417n5z35ynmL65-hmQXBJkPLvbJL_UkzAgimEa4Sjh8YgHtKR2tCSas65vpsh0YyIXTny7Puzb8Hvs9uNxGPMfSyStkq2pMn3jZpzjfKsgYMMKDzdouOUktqhPACnhr6Qsx3ZdCTubWI8EkLpQsj4nYxjihAKD9mM-9LyUQGRh4mQOOQ0U4zY3qAE6fPOz-Upa5efnAlQhO0GtTkcOHiosY%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the cert. Then you can require the CA support 
revocation using the same validation process as was used to confirm certificate 
authorization. With each cert logged in CT, everyone in the world will know 
exactly how to revoke an unauthorized or no-longer-wanted cert.

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, June 1, 2018 1:02 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 
> requires the CA (not some reseller) to revoke the certificate within 24 hours 
> if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, 
> they must revoke once made aware of the situation (in this case by you 
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. 
> In
practice, I believe that the requirement Jakob quoted is rarely invoked because 
(despite the examples), the language is too vague and narrow. It can also be 
quite difficult for a CA to verify that the revocation request is coming from 
the legitimate domain name registrant [1], making it less likely the CA will 
take action.

I've made a couple of attempts to fix this, resulting in the current language 
proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate should not 
be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by 
proving that they control the domain name using one of the BR 3.2.2.4 methods, 
but this is a problem because most CAs don't support every domain validation 
method and many domains are configured such that some validation methods can't 
be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

Which is yet another reason why removing method 1 and method 5 was a good idea. 
 Do any of the other methods share the same problem? Maybe IP address 
verification right now.

 

From: Ryan Sleevi  
Sent: Friday, June 1, 2018 2:51 PM
To: Jeremy Rowley 
Cc: Wayne Thayer ; Jakob Bohm ; 
mozilla-dev-security-policy 
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

You know I'm strongly supportive of requiring disclosure of validation methods, 
for the many benefits it brings, I'm not sure how that would address the 
concern.

 

Consider a certificate validated under .5. Would Richard now need to hire a 
lawyer to say they own their domain name now?

 

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the cert. Then you can require the CA support 
revocation using the same validation process as was used to confirm certificate 
authorization. With each cert logged in CT, everyone in the world will know 
exactly how to revoke an unauthorized or no-longer-wanted cert.


-Original Message-
From: dev-security-policy 
mailto:digicert@lists.mozilla.org> > On Behalf Of Wayne Thayer via 
dev-security-policy
Sent: Friday, June 1, 2018 1:02 PM
To: Jakob Bohm mailto:jb-mozi...@wisemo.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 
> requires the CA (not some reseller) to revoke the certificate within 24 hours 
> if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, 
> they must revoke once made aware of the situation (in this case by you 
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. 
> In
practice, I believe that the requirement Jakob quoted is rarely invoked because 
(despite the examples), the language is too vague and narrow. It can also be 
quite difficult for a CA to verify that the revocation request is coming from 
the legitimate domain name registrant [1], making it less likely the CA will 
take action.

I've made a couple of attempts to fix this, resulting in the current language 
proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate should not 
be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by 
proving that they control the domain name using one of the BR 3.2.2.4 methods, 
but this is a problem because most CAs don't support every domain validation 
method and many domains are configured such that some validation methods can't 
be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

I was thinking more that this would be the minimum where a CA is required to 
revoke. For example, if the revocation requester can demonstrate control in the 
same fashion as the certificate issued, then the CA MUST revoke. This likely 
wouldn’t be the only way a CA would be required to revoke. And I do agree it 
won’t solve all cases. However, if the CA was able to issue a certificate using 
a particular domain control mechanism, shouldn’t they also be able to complete 
the domain control mechanism for revocation? Perhaps the domain holder cannot 
but that shouldn’t necessarily prevent the CA from supporting it. 

 

 

From: Ryan Sleevi  
Sent: Friday, June 1, 2018 4:08 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; Wayne Thayer ; Jakob Bohm 
; mozilla-dev-security-policy 

Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

Yes, as mentioned in the CABF in the first link Wayne provided, even for our 
other methods, it can be problematic for domain holders to demonstrate control 
using particular methods. As Joanna mentioned, .2 can be problematic in a 
post-WHOIS world.

 

I realize that shooting down suggestions doesn't help us build sustainable 
solutions, but this was a problem we thought about a lot in the context of the 
CT redaction discussions, because the only 'effective' mitigation to 
inappropriate redaction was reveal-(and-revoke) - that is, reveal the redacted 
name, and possibly revoke the cert if you don't like what was revealed. Trying 
to decide how to authorize that request and what the consequences of that would 
be occupied a substantial part of our time (... I promise I didn't hate 
redaction "just because").

 

As an example scenario beyond what Wayne pointed out in the 
https://cabforum.org/pipermail/public/2018-January/012824.html link, consider 
such situations such as All CAs being required to support all validation 
methods for revocation. One possible scenario is a lack of interoperable 
interpretations of some methods (yet compliant with the letter) - for example, 
GlobalSign's validation methods compared to Let's Encrypt's use of the (draft) 
ACME validation methods, which comply with the letter but are different 
protocols. Another possible scenario is that a CA only supports a given method 
for revocation, not issuance, and thus the robustness of it and the testing of 
it is far weaker than might be expected (and detected) for domain validation. 

 

Understandably, we can try to patch those two examples I gave (and there is 
useful result in doing so), such as trying to further specify exactly how 
domains are validated, or potentially requiring CAs to also support all such 
methods for domain validation as well (although determining whether that means 
CAs MUST also support DV is a related and natural implication that follows that 
sort of policy). However, I was trying to present them to indicate the sort of 
holistic challenges we should think about, and why it's not quite as easy as 
'revoke the same way you validated' or 'validate using any/every possible 
method'.

 

So what does that mean for Richard? Well, I agree with Jakob in that he quoted 
the appropriate section, and there is a reasonable expectation in principle for 
the CA to do due diligence to investigate for possible revocation. And I think 
Wayne's directions on revocation do offer a number of important contributions 
to that, by providing some degree of flexibility for CAs to do meaningful 
investigations (although with some degree of transparency inevitably being 
needed when offering CA discretion). And I think the Root Stores have a role to 
play in how they communicate that expectation to CAs, such that domain holders 
have recourse if the CA is not taking meaningful steps.

 

On Fri, Jun 1, 2018 at 5:42 PM, Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

Which is yet another reason why removing method 1 and method 5 was a good idea. 
 Do any of the other methods share the same problem? Maybe IP address 
verification right now.

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Friday, June 1, 2018 2:51 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; Jakob 
Bohm mailto:jb-mozi...@wisemo.com> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >


Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

You know I'm strongly supportive of requiring disclosure of validation methods, 
for the many benefits it brings, I'm not sure how that would address the 
concern.

 

Consider a certificate validated under .5. Would Richard now need to hire a 
lawyer to say they own their domain name now?

 

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.o

RE: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

RFC 6844: "The Certification Authority Authorization (CAA) DNS Resource
Record
   allows a DNS domain name holder to specify the Certification
   Authorities (CAs) authorized to issue certificates for that domain. "

CAA record checks would be outside the scope of revocation requests. 

I'm not sure I agree with " In any event, proof of ability to modify the
authoritative DNS over each label in the certificate should almost certainly
suffice to revoke a previously issued certificate that relied exclusively
upon just about any other sort of domain validation."

But only because I doubt every CA supports DNS checking, and I know several
companies where the people operating the DNS are not the same  entities
authorized to manage certificates. 


-Original Message-
From: dev-security-policy

On Behalf Of Matthew Hardeman via dev-security-policy
Sent: Friday, June 1, 2018 5:17 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy
; Jakob Bohm
; Wayne Thayer 
Subject: Re: Namecheap refused to revoke certificate despite domain owner
changed

On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is one of the reasons I think we should require an OID specifying 
> the validation method be included in the cert. Then you can require 
> the CA support revocation using the same validation process as was 
> used to confirm certificate authorization. With each cert logged in 
> CT, everyone in the world will know exactly how to revoke an 
> unauthorized or no-longer-wanted cert.
>
>
I agree that it would be forensically interesting to have that data
available in the certificate.  I question whether a policy of using only the
same method of demonstrating control anew is appropriate as a policy for
granting revocation.

There is a hierarchy of supremacy in domain validation.  The party
controlling the NS delegations from the registry has absolute precedence
over the present effective DNS server administrator, should they choose to
flex it.  The party immediately in effective control of the authoritative
DNS takes precedence over a website admin within the domain.

Consider that now current CAA records and policy (for good cause, even)
might presently prohibit successful validation via the method previously
utilized to acquire the certificate that the current domain holder wishes to
have revoked.  (Even if only by specifying a new CA, rather than the CA that
previously issued the certificate for which revocation is being
sought.)  Would you then advocate that if the validation can succeed -- save
for the CAA mismatch -- that this be regarded as sufficient evidence to
revoke?  That probably deserves some careful thought.

In any event, proof of ability to modify the authoritative DNS over each
label in the certificate should almost certainly suffice to revoke a
previously issued certificate that relied exclusively upon just about any
other sort of domain validation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Jeremy Rowley via dev-security-policy]

Punctuation differences are not enough to register a name in the us, or at 
least in the jurisdictions here I’m aware of.  

> On Jun 4, 2018, at 1:04 AM, Ryan Hurst via dev-security-policy 
>  wrote:
> 
> I apologize, I originally wrote in haste and did not clearly state what I
> was suggesting.
> 
> Specifically, while it is typical for a given jurisdiction (state, etc) to
> require a name to be unique, it is typically not a requirement for it to
> not be so unique that it can not be confused for another name. For example,
> I have seen businesses registered with punctuation and without; I have also
> seen non-latin characters in use in business names this clearly has the
> potential to introduce name confusion.
> 
> Ryan
> 
> On Fri, Jun 1, 2018 at 11:55 PM, Matthew Hardeman 
> wrote:
> 
>> 
>> 
>> On Fri, Jun 1, 2018 at 10:28 AM, Ryan Hurst via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> 
>>> 
>>> re: Most of the government offices responsible for approving entity
>>> creation are concerned first and foremost with ensuring that a unique name
>>> within their jurisdiction is chosen
>>> 
>>> What makes you say that, most jurisdictions have no such requirement.
>>> 
>>> 
>> This was anecdotal, based on my own experience with formation of various
>> limited liability entities in several US states.
>> 
>> Even my own state of Alabama, for example, (typically regarded as pretty
>> backwards) has strong policies and procedures in place for this.
>> 
>> In Alabama, formation of a limited liability entity whether a Corporation
>> or LLC, etc, begins with a filing in the relevant county probate court of
>> an Articles of Incorporation, Articles or Organization, trust formation
>> documents, or similar.  As part of the mandatory filing package for those
>> document types, a name reservation certificate (which will be validated by
>> the probate court) from the Alabama Secretary of State will be required.
>> The filer must obtain those directly from the appropriate office of the
>> Alabama Secretary of State.  (It can be done online, with a credit card.
>> The system enforces entity name uniqueness.)
>> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Cert transition update

[Jeremy Rowley via dev-security-policy]

We want to share the latest update on the Symantec distrust plan and seek
input from the community.  Below is a high level summary:

 

The majority of root program operators plan to either partially or fully
distrust Symantec roots by Q3 CY 2018, and no later than Q2 CY 2019.  All
TLS certificates issued from these roots will be impacted.  Please see list
of roots below. We've contacted all of the impacted customers so everyone
should be fully aware of the need at this point, even if some subscribers
are waiting to replace their certificates until after the summer.

 

Key Dates

.March 2018 - Beginning of phased removal of trust by root
program operators for Symantec TLS certificates issued prior to June 1,
2016.

.October 2018 - Full removal of trust of Symantec-issued TLS
certificates by root program operators.

.By no later than Q2 CY 2019 - Full removal of Symantec-issued
TLS certificates from all major root program operators.

 

The cert transition extends beyond TLS certificates, and we plan to migrate
most publicly-trusted non-TLS certificate issuance to DigiCert roots on
October 1st. However, the exception list of customers unable to migrate
s/MIME certificates will be larger than the TLS-side as these certificates
are often used with government ID cards or in facilities without ready
access. We'll work with these customers to replace their issuing CAs with
DigiCert issuing CAs so all certificates going forward will chain to one of
the ten DigiCert root certificates. 

 

I'd definitely love the feedback on the above and public comments.

 

Impacted Roots and Usage:

Root  EKU

GeoTrust Global CAServer Authentication; Client Authentication;
Secure Email; Code Signing; Time Stamping

GeoTrust Global CA 2 Server Authentication; Client Authentication; Code
Signing; Secure Email; Time Stamping

GeoTrust Primary Certification Authority Server Authentication;
Client Authentication; Secure Email; Code Signing

GeoTrust Primary Certification Authority - G2 Server Authentication;
Client Authentication; Secure Email; Code Signing; Time Stamping

GeoTrust Primary Certification Authority - G3 Server Authentication;
Client Authentication; Secure Email; Code Signing; Time Stamping

GeoTrust Universal CA   Server Authentication; Client Authentication; Secure
Email; Code Signing; Time Stamping

GeoTrust Universal CA 2  Server Authentication; Client
Authentication; Code Signing; Secure Email; Time Stamping

Symantec Class 1 Public Primary Certification Authority - G4 Client
Authentication; Secure Email

Symantec Class 1 Public Primary Certification Authority - G6 Client
Authentication; Secure Email

Symantec Class 2 Public Primary Certification Authority - G4 Client
Authentication; Secure Email

Symantec Class 2 Public Primary Certification Authority - G6 Client
Authentication; Secure Email

Symantec Class 3 Public Primary Certification Authority - G4 Server
Authentication; Client Authentication; Secure Email; Code Signing; Time
Stamping

Symantec Class 3 Public Primary Certification Authority - G6 Server
Authentication; Client Authentication; Secure Email; Code Signing; Time
Stamping

thawte Primary Root CA Server Authentication; Client Authentication; Secure
Email; Code Signing

thawte Primary Root CA - G2  Server Authentication; Client
Authentication; Secure Email; Code Signing; Time Stamping

thawte Primary Root CA - G3  Server Authentication; Client
Authentication; Secure Email; Code Signing; Time Stamping

VeriSign Class 1 Public Primary Certification Authority - G3
Client Authentication; Secure Email

VeriSign Class 2 Public Primary Certification Authority - G3
Client Authentication; Code Signing; Secure Email

VeriSign Class 3 Public Primary Certification Authority - G3
Code Signing; Server Authentication; Client Authentication; Secure Email

VeriSign Class 3 Public Primary Certification Authority - G4
Server Authentication; Client Authentication; Secure Email; Code Signing;
Time Stamping

VeriSign Class 3 Public Primary Certification Authority - G5
Server Authentication; Client Authentication; Secure Email; Code Signing

VeriSign Universal Root Certification Authority   Server Authentication;
Client Authentication; Secure Email; Code Signing; Time Stamping

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Possible violation of CAA by nazwa.pl

[Jeremy Rowley via dev-security-policy]

I think the desire to categorize these is more to make sense of where the 
distrust line is. No one wants to end up on the same boat as Symantec, and 
there aren't clear guidelines on how to prevent that from happening to a CA. 

Pretty much every CA mis-issues at some point on an infinite timeline, and the 
lack of certainty on browser reaction to the mis-issuance makes it hard to 
determine the best corrective course of action should be. Obviously, public 
discussion on issues as they happen is the best way to figure that out, but 
explaining to management that the consequences of various misissuances could 
range from root removal to a simple apology, depending on the browser, is 
pretty difficult. If you follow the list closely, the levels of mis-issuance 
are a lot more clear. For CAs that don’t' follow as closely, it can be a lot 
scarier.  


-Original Message-
From: dev-security-policy 
 On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, July 27, 2018 8:01 PM
To: Tim Hollebeek 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm 

Subject: Re: Possible violation of CAA by nazwa.pl

I disagree that a series of categories is good or helpful to the community.

I think the framing is generally adopted by CAs that want to see shades of gray 
in non-compliance, in order to downplay risk or downplay their lack of 
compliance.

As to the Forum, browsers have tried multiple times to introduce definitions. 
Gerv had previously supported a single definition for any matter of 
non-compliance, in order to appropriately and adequately inform CAs about 
expectations, but CAs were still opposed.

By focusing on that singular matter, ontologies can be avoided, as can the 
inevitable disagreements about impact and consequence that detract from a more 
meaningful focus on action and remediation.

On Sat, Jul 28, 2018 at 4:39 AM Tim Hollebeek via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> I agree.
>
> I've actually thought about adding definitions of categories of 
> misissuance to the BRs before.  Some of the requirements like 
> revocation are really hard to write and understand if you don't first 
> categorize all the misissuance use cases, many of which are very, very 
> different.  And just when I think I have a reasonable ontology of them 
> in my head ... someone usually goes and invents a new one.
>
> Despite how much people like to talk about it, misissuance isn't a 
> defined term anywhere, AFAIK.  It can lead to a lot confusing 
> discussions, even among experts at the CA/Browser Forum.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy  > bounces+tim.hollebeek=digicert@lists.mozilla.org> On Behalf Of 
> > bounces+Jakob
> > Bohm via dev-security-policy
> > Sent: Friday, July 27, 2018 2:46 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Possible violation of CAA by nazwa.pl
> >
> > On 26/07/2018 23:04, Matthew Hardeman wrote:
> > > On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via 
> > > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > >
> > >>
> > >>> The party actually running the authoritative DNS servers is in 
> > >>> control
> > >> of the domain.
> > >>
> > >> I'm not sure I agree. They can control the domain, but they are 
> > >> supposed to be subordinate of the domain owner. If they did 
> > >> something without the owner consent/approval, it really looks 
> > >> like a domain
> hijacking.
> > >
> > >
> > > But the agreement under which they're supposed to be subordinate 
> > > to the domain owner is a private matter between the domain owner 
> > > and the party managing the authoritative DNS.  Even if this were 
> > > domain hijacking, a certificate issued that relied upon a proper 
> > > domain validation method is still proper issuance, technically.  
> > > Once this comes to light, there may be grounds for the proper 
> > > owner to get the certificate revoked, but the initial issuance was 
> > > proper as long as the validation was properly performed.
> > >
> > >
> > >>
> > >>
> > >>> I'm not suggesting that the CA did anything untoward in issuing 
> > >>> this certificate.  I am not suggesting that at all.
> > >>
> > >> My opinion is that if the CA was aware that the owner didn't 
> > >> ask/consent to that issuance, If it's not a misissuance according 
> > >> to the BRs, it should be.
> > >
> > >
> > > Others can weigh in, but I'm fairly certain that it is not 
> > > misissuance according to the BRs.  Furthermore, with respect to 
> > > issuance via domain validation, there's an intentional focus on 
> > > demonstrated control rather than ownership, as ownership is a 
> > > concept which can't really be securely validated in an automated 
> > > fashion.  As such, I suspect it's unlikely that the industry or 
> > > browsers would accept such a
> > change.
> > >
> > >
> >
> > I see this as a clear case of the profound confusion caused by the
> community
> > sometim

RE: Possible violation of CAA by nazwa.pl

[Jeremy Rowley via dev-security-policy]

I don’t think that’s entirely accurate. People like clear guidelines on what 
will happen if they do x, y, or z.  This applies to both revocation and 
distrust.  Historically, there’s times when a CA must revoke the certs and 
times where the browsers don’t require revocation. This leads to confusion 
about the likely outcome of each mis-issuance.  Trying to define the different 
categories of misissuance is about trying to make sense of why some CAs must 
revoke all impacted certs, some CAs are distrusted, and some CAs have more 
remedial action plan. Of course, all mis-issuance is bad as it illustrates a 
gap in the CAs process or procedures. However, the browser action in response 
seems to fall into various categories. 

 

The better definition of misissuance and expected action is probably simpler. 
Based on watching the various mis-issuances (including our own), the general 
framework is more along the lines of:

1.  Disregard for the guidelines or unwillingness to follow the browser 
policies = Distrust
2.  Impacts security of a website = Revoke
3.  Doesn’t impact security but a violation of the BRs = Possible revoke 
but depends on discussions with the browser and public

 

 

From: Ryan Sleevi  
Sent: Saturday, July 28, 2018 8:25 PM
To: Jeremy Rowley 
Cc: Jakob Bohm ; Tim Hollebeek 
; mozilla-dev-security-pol...@lists.mozilla.org; 
r...@sleevi.com
Subject: Re: Possible violation of CAA by nazwa.pl

 

 

 

On Sat, Jul 28, 2018 at 2:17 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

I think the desire to categorize these is more to make sense of where the 
distrust line is. No one wants to end up on the same boat as Symantec, and 
there aren't clear guidelines on how to prevent that from happening to a CA. 

 

I don’t think it’s that cut and dry. Everything enumerated highlights a failure 
of process - whether that failure was technical or procedural is far less 
important to the frequency, detection, and remediation of those failures. The 
expectation is for the CA to design their systems in a way to prevent as many 
human failures as possible - and there’s little excuse for the technical ones - 
while also having robust systems in place to detect and remediate.

 

The hidden thread in this is less about CAs being distrusted, and more about 
finding reasons to not revoke certs - as if some failures are less than 
revocation worthy. Yet that’s flossing over the largest systemic issue in our 
industry, which is the lack of certificate agility (in issuance or 
replacement). Requiring revocation acknowledges that our end state should be 
the old cert is replaced transparently by the new cert and no systems break - 
and any difficulty in that either rests with the CA for not investing enough in 
meaningful systems (automatable validation like those based on DNS, 
interoperable automated issuance protocols like ACME), or on the Subscriber for 
not investing in automation.

 

Framing it as somehow being about the Browser reaction is thus incorrect - ANY 
single instance of misissuance could be worthy of distrust, as could a 
sustained pattern. Browsers are only going to get better at managing that 
impact to their users, so both CAs need to get better preventing and 
Subscribers need to take advantage of the better automation solutions.

 

 

 



Pretty much every CA mis-issues at some point on an infinite timeline, and the 
lack of certainty on browser reaction to the mis-issuance makes it hard to 
determine the best corrective course of action should be. Obviously, public 
discussion on issues as they happen is the best way to figure that out, but 
explaining to management that the consequences of various misissuances could 
range from root removal to a simple apology, depending on the browser, is 
pretty difficult. If you follow the list closely, the levels of mis-issuance 
are a lot more clear. For CAs that don’t' follow as closely, it can be a lot 
scarier.  


-Original Message-
From: dev-security-policy 
mailto:digicert@lists.mozilla.org> > On Behalf Of Ryan Sleevi via 
dev-security-policy
Sent: Friday, July 27, 2018 8:01 PM
To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
 ; Jakob Bohm 
mailto:jb-mozi...@wisemo.com> >
Subject: Re: Possible violation of CAA by nazwa.pl  

I disagree that a series of categories is good or helpful to the community.

I think the framing is generally adopted by CAs that want to see shades of gray 
in non-compliance, in order to downplay risk or downplay their lack of 
compliance.

As to the Forum, browsers have tried multiple times to introduce definitions. 
Gerv had previously supported a single definition for any matter of 
non-compliance, in order to appropriately and adequately inform CAs about 
expectations, but CAs were still opposed.

By focusing on that singular matter, ontologies can be a

Issuance with improper domain validation

[Jeremy Rowley via dev-security-policy]

I posted this to Bugzilla last night. Basically, we had an issue with
validation that resulted in some certs issuing without proper (post-Aug 1)
domain verification. Still working out how many. The major reason was lack
of training by the validation staff combined with a lack of strict document
controls in the early part of the Symantec-DigiCert transition. 

 

1. How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.

 

On 2018/08/07 at 17:00 UTC, a customer submitted a request for information
about our validation process for the verification of four of their domains.
Upon investigation, we found that the four domains were not properly
validated using a post-Aug 1 domain validation method.  When attempting to
revalidated the domains prior to August 1, the random value was sent to an
address other than the WHOIS contact. This launched a broader investigation
into our overall revalidation efforts. This investigation is ongoing.  

 

2. A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.

>From approximately February through April 2018, DigiCert permitted some
legacy Symantec customers to use Method 1 to validate their domains. Use of
the method was subject to manager approval and reserved only for those
companies that had urgent replacement deadlines that could not be met with
an alternative validation method. Under this process, prior to approval, the
validation staff was required to match the WHOIS company information and
obtain approval using the WHOIS email address. 

 

Around April, this process was modified to include a BR-compliant Random
Value that the validation staff sent using the WHOIS contact information.
Use of the random value indicated acceptance.  Adding the random value
effectively transformed the validation from Method 1 to Method 2. The email
could include multiple domains with the understanding that the WHOIS contact
information had to match each domain listed. 

 

We believe that in some cases either the validation staff failed to match
the WHOIS contact information for each domain listed, approving the
certificate solely based on the existing verified registrant info, or the
system did not check whether the WHOIS contact information matched the email
address used in the original confirmation. 

 

On Aug 1, 2018, Ballot 218 took effect, deprecating Method 1.

 

On, August 7, 2018, a customer requested the audit trail of a certificate
issued using our new process. Upon review, validation management discovered
the validation was improper because the previously verified email contact
information did not match the WHOIS contact information.  This discovery
created an escalation up to management.

 

On August 13, 2018, we stopped all issuance based on the process that
converted Method 1 validations to Method 2 validations. 

 

We're currently investigating and will post an update when we know the
number of certificates and more about what went wrong. For now, we know the
number of impacted certificates is just under 2,500. We should have a
clearer picture shortly, after we have conducted a manual review of all
2,500 certificates.

 

3. Whether your CA has stopped, or has not yet stopped, issuing certificates
with the problem. A statement that you have will be considered a pledge to
the community; a statement that you have not requires an explanation.

 

On August 13, although most of these validations were likely properly
completed, we stopped issuance using information converted from Method 1
until completing a more thorough investigation.

 

4. A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued.

 

Approximately 2,500 certificates are under review for validation issues. We
wanted to get the incident report out quickly as an FYI while our
investigation continues. We'll update this section in a final report.

 

5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged to
CT and then list the fingerprints or crt.sh IDs, either in the report or as
an attached spreadsheet, with one list per distinct problem.

 

Still under review. We will upload them to the bug once we have a complete
list. Because the error was human, we are reviewing each validation to
determine whether Method 2 was correctly used.  Once we complete our review,
we'll post a Bugzilla attachment with the links for revoked certificates.

 

6. Explanation about how and why the mistakes were made or bugs introduced,

RE: New certificate from compromised key

[Jeremy Rowley via dev-security-policy]

Thanks. We've revoked the cert and are looking into what happened and will post 
more information as we figure out what happened.  


-Original Message-
From: dev-security-policy  On 
Behalf Of Hanno Böck via dev-security-policy
Sent: Friday, August 17, 2018 7:16 PM
To: dev-security-policy@lists.mozilla.org
Subject: New certificate from compromised key

Hi,

Some of you may remember the discussion about embedded private keys in 
Blizzard's battle.net software here:
https://clicktime.symantec.com/a/1/XSDo7RID7Ms9aljAAOVAKoWLKhovvM_IrWUufr3rx9Y=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D&u=https%3A%2F%2Fgroups.google.com%2Fforum%2F%23%21msg%2Fmozilla.dev.security.policy%2Fpk039T_wPrI%2FVYi629oGCwAJ

One of the certificates with a compromised key back then was issued by
Digicert:
https://clicktime.symantec.com/a/1/8QluDmhQ8mTJ30JiFIlP9Ea07fo7BeZ76x4vHiRQ4Es=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D&u=https%3A%2F%2Fcrt.sh%2F%3Fid%3D287530764

I noticed that a new certificate for a different domain, but with that same 
private key has been issued:
https://clicktime.symantec.com/a/1/UztZ9c6dq7VDtqVztbSn0ztsSjdjchyTG87cjFnvYyc=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D&u=https%3A%2F%2Fcrt.sh%2F%3Fid%3D638323656

I tried to report it to rev...@digicert.com - but that address was replying 
with an error message...

--
Hanno Böck
https://clicktime.symantec.com/a/1/RJ969RojJELZVkzGgzMk2SN78MqUTvCuXRkZHP0djk4=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D&u=https%3A%2F%2Fhboeck.de%2F

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/hc7xtvs26hqWeA42At7XWr7eeiDnWj1n6xCl__YKAGc=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

Jake's concern is legit if you believe certain assumptions. Criticizing his
rationale doesn't seem correct, especially since Google does indeed have a
root store. Although not traditional, Google runs a store of blacklisted CAs
(see Symantec), which is every bit as effective as controlling CA compliance
and operation as the inclusion process.

ASSUMPTION: Google and Mozilla are the two browsers policing CA policy and
operations. This is fairly true as they are the two engaged publicly in
posting about issues and deciding publicly what to trust and distrust.
ASSUMPTION: Google will never distrust itself and likely won't be overly
harsh on itself if Google misses a few BRs here or there. This is probably
also true. Not many companies spend on creating infrastructure just to get
it kicked out.  Note that I personally haven't found Google unreasonable
when there's a compliance issue as long as the disclosure is timely and
complete. As long as they keep up that same standard for requiring prompt
disclosure and remediation, this assumption is flawed.
FACT: As a browser, Google already interprets the CA/Browser requirements in
many ways via, intentionally or not.  The Google's policies, and how Google
implements Chrome are all closely watched by CAs and help dictate how we
interpret the various requirements.  
This fact combined with the assumption that Google will never distrust
itself jumps to a conclusion that Google will only interpreting the BRs in
Google CA's best interests. Why wouldn't they? Google is a for profit
company. Self-promotion is kind-of in the description.
FACT: Google is a module peer in Mozilla NSS, which means Google has
significant influence over BR interpretation, the penalties related to CA
mis-issuance, and the requirements a CA has for operating within the space.
This gives one CA a lot of influence over how Mozilla treats the other CAs. 
The change in paradigm means a reasonable person (like Jake) could be
concerned with potential obfuscation of problems, a loss of policy
enforcement, and various other nefarious acts. I think most of us Mozilla
users see Mozilla as a watch-dog of the Internet so this combination of
Browser-CA-module peer reasonably causes unease. 

Anyway, my two cents are that Jake's fear is reasonable and shouldn't be
minimized just because you have to trust some browser, especially where it
means trusting a browser that is separate from the one being discussed on
this forum (Mozilla).  
Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, September 20, 2018 2:44 AM
To: dev-security-policy@lists.mozilla.org
Cc: Jake Weisz 
Subject: Re: Google Trust Services Root Inclusion Request

On Mon, 17 Sep 2018 18:41:07 -0500
Jake Weisz via dev-security-policy
 wrote:

> I guess under this logic, I withdraw my protest. As you say, Google 
> could simply start using these certificates, and Mozilla executives 
> would force you to accept them regardless of any policy violations in 
> order to keep people using Firefox. This whole process appears to 
> mostly just be a veneer of legitimacy on a process roughly akin to the 
> fair and democratic election of Vladimir Putin. :| As long as Google 
> remains legally answerable to no authority and an effective monopoly 
> in half a dozen markets, there is roughly no point for Mozilla to 
> maintain a CA policy: It should simply use Chrome's trusted store.

I think you've misunderstood. What happened was that somebody turned your
logic on itself, to show that it tears itself to pieces. The right
conclusion to draw from that is "My whole position is senseless and I must
reconsider".

It's analogous to the mathematical "proof by contradiction".

It certainly isn't our intent to say you're right, but only to follow your
position to its self-defeating logical conclusion.

Also, in passing, it would help if you knew that, for example, Chrome
doesn't have a trust store, Google operates a root trust programme in its
role as an Operating system vendor (for Android) but the Chrome browser uses
the OS-provided trust store, a Chrome on Windows trusts the various obscure
Government CAs that Microsoft decided are trustworthy, a Chrome on macOS
trusts whatever Apple trusts, and so on.


> Google's explanation in their announcement seems to confirm my
> statement: That buying roots from GlobalSign is effectively 
> backdooring the CA process and making their certificates work in 
> products which would not otherwise trust them.

Mechanically it is necessary to have trust from existing systems or you
can't run a new CA for many years while you wait for new systems that do
trust you to be deployed.

[ For example for Let's Encrypt this was ensured by obtaining cross
signatures on the Let's Encrypt intermediates from Identrust's DST Root CA
X3. ]

This fact makes a difference to what a CA might plausibly choose to do,
operationally, but doesn't alter how trustworthy, or otherwise tha

RE: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

I also should also emphasize that I’m speaking as Jeremy Rowley, not as 
DigiCert.

 

Note that I didn’t say Google controlled the policy. However, as a module peer, 
Google does have significant influence over the policy and what CAs are trusted 
by Mozilla. Although everyone can participate in Mozilla discussions publicly, 
it’s a fallacy to state that a general participant has similar sway or 
authority to a module peer. That’s the whole point of having a separate class 
for peers compared to us general public.  With Google acting as a CA and module 
peer, you now have one CA heavily influencing who its competitors are, how its 
competitors operate, and what its competitors can do.  Although I personally 
find that you never misuse your power as a module peer, I can see how Jake has 
concerns that Google (as a CA) has very heavy influence over the platform that 
has historically been the CA watchdog (Mozilla). 

 

The circumstances are different between the scenarios you describe with respect 
to the other browsers, as is market share.  If Microsoft wants to change CAs 
(and they already use multiple), they can without impacting public perception. 
If Apple wants to use another CA, they can without people commenting how odd it 
is that Apple doesn’t use the Apple CA. With Google controlling the CA and the 
Google browser, all incentive to eliminate any misbehaving Google CA disappears 
for financial reasons, public perception, and because Google can control the 
messaging (through marketshare and influence over Mozilla policy). Note that 
there is historical precedent for Google treating Google special – i.e. the 
exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s 
concerns should not be discarded so readily. 

 

 

 

From: Ryan Sleevi  
Sent: Wednesday, September 26, 2018 12:43 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services Root Inclusion Request

 

(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going 
to emphasize that this response is in a personal capacity)



On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Jake's concern is legit if you believe certain assumptions. Criticizing his
rationale doesn't seem correct, especially since Google does indeed have a
root store. Although not traditional, Google runs a store of blacklisted CAs
(see Symantec), which is every bit as effective as controlling CA compliance
and operation as the inclusion process.

 

To be clear: Google does indeed operate root stores on a host of devices, 
including Android and ChromeOS, not to mention Google Cloud functionality.

 

FACT: As a browser, Google already interprets the CA/Browser requirements in
many ways via, intentionally or not.  The Google's policies, and how Google
implements Chrome are all closely watched by CAs and help dictate how we
interpret the various requirements.  

 

This fact combined with the assumption that Google will never distrust
itself jumps to a conclusion that Google will only interpreting the BRs in
Google CA's best interests. Why wouldn't they? Google is a for profit
company. Self-promotion is kind-of in the description.

 

The problem with this assumption, or at least what logically follows, is that 
every Browser would behave the same, beneficient towards the CA(s) they use for 
services. For example, Microsoft operates a root program, yet is also trusted 
by Mozilla through the subordinate CAs provided through the Baltimore 
Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates 
a root program, yet is also trusted by Mozilla through subordinate CAs provided 
through the GeoTrust hierarchy, which is owned by... DigiCert.

 

Google operates a root program, yet is also trusted by Mozilla through... the 
acquisition of key material (from GlobalSign) and the operation of independent 
roots.

 

If we accept this assumption as sound, then it seems the argument is that 
DigiCert can also never be distrusted, and interpretations will always be to 
the benefit of DigiCert, because to distrust DigiCert or take sanction would be 
to disrupt 'critical' services like Azure or iTunes.

 

Alternatively, one could argue/make assumptions that by virtue of Google 
previously having operated a subordinate under the GeoTrust hierarchy 
(DigiCert, formerly Symantec), that they've demonstrated it's possible to 
operate as subordinate or root. They demonstrably took steps regarding the 
Symantec hierarchy, even as it was the basis for trust of Google services. In 
that model, if Google CA were to take actions detrimental to the ecosystem, 
Google may interpret the BRs in the Internet trust and stabilities best 
interests, distrust the Google CA, and force Google to transition to an 
alternative solution precisely to avoid the alternative

RE: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

Oh – I totally agree with you on the Google inclusion issue. Google meets the 
requirements for inclusion in Mozilla’s root policy so there’s no reason to 
exclude them. They have an audited CPS, support a community broader with certs 
than just Google, and have operated a CA without problems in the past. The 
discussion on Mozilla’s independence is important IMO where a) a Mozilla 
competitor as a module peer and b) having that same person also belong to a CA. 
There are legit concerns. Has any other CA served as a module owner? If not, 
why? I know Tim Hollebeek would be interested in being a peer. If he’s not 
permitted to be a peer, why not?

 

To be fair, separating out Ryan as a Google browser representative and Ryan as 
a module peer is…hard. Perhaps, he specifically is seen as more influential 
(from my point of view) than others simply because of his dual role.  

 

As I said before, Ryan’s a good module peer so I don’t disagree with your 
conclusion or any decision to keep him in that spot. But I think openness 
should include respectful conversation on the impact of influences, perceived 
or real, on the Mozilla direction.  What might help alleviate concerns is to 
describe how you (as a module owner) are going to ensure that if Ryan is 
reviewing and approving code or CA policies, they won’t be unfairly biased 
towards google or against its competitors? Maybe that’s a bad question, but I’m 
spit-balling on how we can move past speculation to address concerns raised.

 

From: Wayne Thayer  
Sent: Wednesday, September 26, 2018 3:39 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: Google Trust Services Root Inclusion Request

 

I'm disputing the conclusion that is being drawn from Jake's concerns, rather 
than the concerns themselves. Primarily, I disagree with the conclusion that 
because Google owns a browser with dominant market share and - due to the 
substantial contributions they make here - because Google has considerable 
influence in this community, they should not be allowed to participate in our 
root program as a CA. Secondarily, I disagree that a Google employee should not 
be a peer of this module due to the potential for a conflict of interest.

 

Unpacking this conclusion in terms of policy it implies, I think the argument 
being made is that any root store operator should be excluded from membership 
in the Mozilla program as a CA, and any employee of a CA should be prohibited 
from being a module peer. The argument is that this will protect us from future 
conflicts of interest (there seems to be agreement that the concern is 
hypothetical at this point).

 

My conclusion is that rather than creating somewhat arbitrary, exclusionary 
rules, we can and should instead rely on the openness and inclusiveness of our 
process to protect us from conflicts of interest. If Google attempts to gain 
preferential treatment for their CA from Mozilla, our community can and will 
identify it, reject it, and hold Mozilla accountable for acting in their best 
interest.

 

On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> >
wrote:

> I also should also emphasize that I’m speaking as Jeremy Rowley, not as
> DigiCert.
>
>
>
> Note that I didn’t say Google controlled the policy. However, as a module
> peer, Google does have significant influence over the policy and what CAs
> are trusted by Mozilla. Although everyone can participate in Mozilla
> discussions publicly, it’s a fallacy to state that a general participant
> has similar sway or authority to a module peer. That’s the whole point of
> having a separate class for peers compared to us general public.  With
> Google acting as a CA and module peer, you now have one CA heavily
> influencing who its competitors are, how its competitors operate, and what
> its competitors can do.  Although I personally find that you never misuse
> your power as a module peer, I can see how Jake has concerns that Google
> (as a CA) has very heavy influence over the platform that has historically
> been the CA watchdog (Mozilla).
>

Jeremy, I think this again deserves calling out, because this is
misrepresenting what module peership does, as well as the CA relationship.

I linked you to the definition of Module Ownership, which highlights and
emphasizes that the module peer is simply a recognized helper. To the
extent there is any influence, it is through the public discussions here.
If your concern is that the title confers some special advantage, that's to
misread what module peer is. If your concern is that the participation -
which provides solid technical arguments as well as the policy alternatives
- is influential, then what you're arguing against is public participation.

You're presenting these as factual, and that's misleading, so I'd like to
highlight what is ac

RE: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

Maybe Jake’s opinion is not being discarded as readily as I supposed. However, 
Jake’s last message left me disturbed that he didn’t feel listened to. 
Apologies if I’m overblowing the issue, which are definitely hypothetical at 
this point. I did want Jake to feel like his input is an important part of this 
discussion board. Not saying anyone made him feel otherwise intentionally of 
course, but his last message seemed frustrated.

 

From: Ryan Sleevi  
Sent: Wednesday, September 26, 2018 10:49 AM
To: Jeremy Rowley 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 

Subject: Re: Google Trust Services Root Inclusion Request

 

 

On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

I also should also emphasize that I’m speaking as Jeremy Rowley, not as 
DigiCert.

 

Note that I didn’t say Google controlled the policy. However, as a module peer, 
Google does have significant influence over the policy and what CAs are trusted 
by Mozilla. Although everyone can participate in Mozilla discussions publicly, 
it’s a fallacy to state that a general participant has similar sway or 
authority to a module peer. That’s the whole point of having a separate class 
for peers compared to us general public.  With Google acting as a CA and module 
peer, you now have one CA heavily influencing who its competitors are, how its 
competitors operate, and what its competitors can do.  Although I personally 
find that you never misuse your power as a module peer, I can see how Jake has 
concerns that Google (as a CA) has very heavy influence over the platform that 
has historically been the CA watchdog (Mozilla).

 

Jeremy, I think this again deserves calling out, because this is 
misrepresenting what module peership does, as well as the CA relationship.

 

I linked you to the definition of Module Ownership, which highlights and 
emphasizes that the module peer is simply a recognized helper. To the extent 
there is any influence, it is through the public discussions here. If your 
concern is that the title confers some special advantage, that's to misread 
what module peer is. If your concern is that the participation - which provides 
solid technical arguments as well as the policy alternatives - is influential, 
then what you're arguing against is public participation.

 

You're presenting these as factual, and that's misleading, so I'd like to 
highlight what is actually entailed.

  

The circumstances are different between the scenarios you describe with respect 
to the other browsers, as is market share.  If Microsoft wants to change CAs 
(and they already use multiple), they can without impacting public perception. 
If Apple wants to use another CA, they can without people commenting how odd it 
is that Apple doesn’t use the Apple CA. With Google controlling the CA and the 
Google browser, all incentive to eliminate any misbehaving Google CA disappears 
for financial reasons, public perception, and because Google can control the 
messaging (through marketshare and influence over Mozilla policy). Note that 
there is historical precedent for Google treating Google special – i.e. the 
exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s 
concerns should not be discarded so readily.

 

I can understand and appreciate why you have this perspective. I disagree that 
it's an accurate representation, and as shown by the previous message, it does 
not have factual basis. I think it's misleading to suggest that the concerns 
are being discarded, much like yours - they're being responded to with 
supporting evidence and careful analysis. However, they do not hold water, and 
while it would be ideal to convince you of this as well, it's equally important 
to be transparent about it.

 

Your argument above seems to boil down to "People would notice if Google 
changed CAs, but not if Microsoft" - yet that's not supported (see, example, 
the usage of Let's Encrypt by Google, or the former usage of WoSign by 
Microsoft). Your argument about incentives entirely ignores the incentives I 
just described to you previously - which look at public perception, internet 
security, and ecosystem stability. Your argument about influence over Mozilla 
policy has already been demonstrated as false and misleading, but it seems you 
won't be convinced by that. And your suggestion of special treatment ignores 
the facts of the situation (the validation issues, the scoping of audits, that 
Apple and 2 other CAs were also included in the exclusion), ignores the more 
significant special treatment granted by other vendors (e.g. Apple's exclusion 
of a host of mismanaged Symantec sub-CAs now under DigiCert's operational 
control), the past precedent (e.g. the gradual distrust of WoSign/StartCom 
through whitelists, of CNNIC through whitelists), and the public discussion 
involved so entirely that it's entirely unfounded.

 

So I think your continued suggestion that it's being discarded so re

DigiCert incident report

[Jeremy Rowley via dev-security-policy]

Hi all, 
 
We issued a single certificate that contained an internal domain. This
certificate was discovered on Oct 16th and revoked on the 17th. We filed the
bug report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1500621 but
are also posting the list for awareness. 
 
Tl;dr. Two validation agents overrode our compliance checks and authorized
issuance of a certificate, completing the domain validation using an
unauthorized email. We're moving from cablint to zlint as our pre-issuance
compliance check and removing the ability of validation agents to override
the compliance check.  
 
Thanks,
Jeremy
 
 
Bug report:
 
1.   How your CA first became aware of the problem (e.g. via a problem
report submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.
 
On 10/16/2018, we were notified by a third party that they had identified an
internal name on a publicly issued certificate, unrelated to their business,
within the past week.
 
2.   A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.
 
10/16/18 A certificate with an internal domain name was reported to us by a
third party
 
10/16/18 We investigated the root cause including the source of the request
and the system that issued the problem certificate. We identified a gap in
our domain pre-validation process that allowed a certificate containing an
internal name to be submitted for validation by a customer. This was
intentional as certificates for use cases other than the WebPKI use the same
validation engine. Once an internal name was queued for validation, a
validation agent overrode the base domain's classification as "private" and
manually performed a WHOIS procedure which is only allowed when automatic
WHOIS data retrieval used to determine the email address for a method 2
email-based domain validation fails. The WHOIS lookup procedure allowed a
validation agent to send a domain confirmation email to the customer
containing a base domain substring of the FQDN, and the customer proceeded
to approve the internal name in response to the method 2 confirmation.
Because the automated WHOIS data retrieval failed in this case, it exposed
an unintended ability for the validation agent to perform an override,
categorize the domain as authorized for the WebPKI, and incorrectly approve
the certificate. 
 
10/17/18 We revoked the one problem certificate and moved the pre-issuance
check behind the validation process, ensuring the system blocks internal
names for public certs regardless of validation staff mistakes. We also
implemented changes on our portals to prevent the gap that allowed internal
names into our domain pre-validation process for WebPKI. We have also
improved our linting process pre-issuance to catch similar situations.
 
10/17/18 We ran a script over our existing certificate database to identify
certs affected by this issue. No additional certificates were identified.
 
3.Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be considered
a pledge to the community; a statement that you have not requires an
explanation.
 
On 10/17/18, we implemented two fixes and a linting enhancement to prevent
this problem from re-occurring.  The linting enhancement checks the
certificate pre-issuance but post validation to ensure no additional issues
exist.
 
 
4.A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued. 
 
 Impact of one certificate, issued on 10/10/2018.
 
 
7.The complete certificate data for the problematic certificates. 
 
   https://crt.sh/?id=845405886
 
6.   Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
 
Limited front-end PSL checking allowed an internal domain name request to be
submitted to our validation queue for human review. Although this is
intentional because we support non-WebPKI systems, there was an override in
the validation process that allowed a validation agent to approve the
certificate for WebPKI. The override was added to allow a validation agent
to override a pre-issuance check when manually accessing WHOIS data and
providing the method 2 Domain Contact email address to the system. The
override feature was only available if the automated WHOIS Domain Contact
email address lookup service failed for the submitted domain. The override
also allowed the validation staff to incorrectly approve non-WebPKI
certificates for WebPKI once validation completed. A combination of these
two problems permitted a 

RE: DigiCert Assured ID Root CA and Global Root CA EV Request

[Jeremy Rowley via dev-security-policy]

We can revoke them all by then. The question is do the browsers really want us 
to? 

Since we started a public discussion, here's the details:

There are several prominent websites that use certs with underscore characters 
in connection with major operations. I was hoping to get permission to post the 
names of these companies before I started a public discussion, but se le vie - 
the discussion already started. These companies are currently in their blackout 
period which ends around mid-Jan. We're scheduled to revoke on Jan 14th per the 
BR change. However, we've heard back from several of them that they won't 
complete the migration by then. This will take down several of the Fortune 
500's websites for a change in the BRs that no one can understand. What we're 
wondering is how the browsers feel about revocation vs. shutting down the 
sites. Public discussion is welcome while I still try to get the names. 
Unfortunately, most companies of that size require a legal review of the 
communication before we can post their name...


-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, November 29, 2018 12:19 PM
To: Wayne Thayer 
Cc: mozilla-dev-security-policy 
Subject: Re: DigiCert Assured ID Root CA and Global Root CA EV Request

This deadline is roughly five weeks before all underscore certificates must be 
revoked (per Ballot SC12). Given the number of underscore certificates under 
various DigiCert operated hierarchies, would you think it appropriate to 
consider whether or not SC12 (and, prior to that, the existing BR requirements 
in force when those certificates were issued) was followed by that date?

More concretely: If DigiCert were to fail to revoke certificates by that 
deadline, would it be a reason to consider denying EV status to these roots / 
removing (if a decision is made to grant) it?

I realize the goal is to close discussion a month prior to that date, but I 
suspect such guidance about the risk of failing to abide by SC12, and failing 
to revoke by January 15, would be incredibly valuable to DigiCert and their 
customers.

On Thu, Nov 29, 2018 at 1:39 PM Wayne Thayer via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Reminder: the 3-week discussion period for this request to EV-enable 
> two DigiCert roots ends next Friday 7-December.
>
> - Wayne
>
> On Fri, Nov 16, 2018 at 5:00 PM Wayne Thayer  wrote:
>
> > This request is to enable EV treatment for the DigiCert Assured ID 
> > Root
> CA
> > and DigiCert Global Root CA as documented in the following bug:
> > https://clicktime.symantec.com/a/1/adm9pTelz2Ycom-02ypNzTJ8tHbaHBnhr
> > 4KpinQCwlc=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1165472
> >
> > * BR Self Assessment is here:
> > https://clicktime.symantec.com/a/1/yUphkRZlY4hiWQzfLqXz_e6_F7P6T9IN6
> > gvhgZ8YgRI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8960346
> >
> > * Summary of Information Gathered and Verified:
> > https://clicktime.symantec.com/a/1/25vbrlC4oNIH-rmRpBBOoNpXg9-MyHD3b
> > Arsg3rBYtU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8987141
> >
> > * Root Certificate Download URLs:
> > ** Global: https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
> > ** Assured: 
> > https://www.digicert.com/CACerts/DigiCertAssuredIDRootCA.crt
> >
> > * CP/CPS:
> > ** CP:
> > https://www.digicert.com

Re: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

Personally, i think you should continue the discussion here. Although you can 
bring it up to whichever ca you use, the reality is that without the browsers 
knowing why the certs cant be replaced and the number, theres no way to gauge 
their reaction to a non compliance. The penalties may include root removal (see 
symantec) so I doubt many cas would be willing to risk a qualification without 
clear guidance from the browsers on the risk associated with the non compliance.

From: dev-security-policy  on 
behalf of pilgrim2223--- via dev-security-policy 

Sent: Friday, December 7, 2018 8:26:42 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Communication: Underscores in dNSNames

Thank you very much for your response!

So at the end of the day I will not get any relief from the browsers, and will 
need to get an exception from my CA?

When I asked the CA they told me to take it here. Feels like the CA is where 
I'm going to have to focus!

Thanks again for your time!

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

This isn't a CA-issue because the risk associated with non-compliance isn't
defined yet. From what I've heard here, the risk is distrust or loss of EV
indicators, which is distrust-like. That's a pretty big thing to push back
on the CA for a non-security issue.  Thus, I think the risk of missing the
underscore revocation date needs to be discussed here so everyone, including
website operators and the relying parties, know first-hand what the risks of
the CA missing the deadline are. If the risk is that there is a note on the
audit, that is an acceptable risk. If the risk is a loss of the
root...probably less so.  Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible. 

-Original Message-
From: dev-security-policy  On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Friday, December 7, 2018 8:39 AM
To: mozilla-dev-security-pol...@lists.mozilla.org; pilgrim2...@gmail.com
Subject: Re: CA Communication: Underscores in dNSNames

Personally, i think you should continue the discussion here. Although you
can bring it up to whichever ca you use, the reality is that without the
browsers knowing why the certs cant be replaced and the number, theres no
way to gauge their reaction to a non compliance. The penalties may include
root removal (see symantec) so I doubt many cas would be willing to risk a
qualification without clear guidance from the browsers on the risk
associated with the non compliance.

From: dev-security-policy  on
behalf of pilgrim2223--- via dev-security-policy

Sent: Friday, December 7, 2018 8:26:42 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Communication: Underscores in dNSNames

Thank you very much for your response!

So at the end of the day I will not get any relief from the browsers, and
will need to get an exception from my CA?

When I asked the CA they told me to take it here. Feels like the CA is where
I'm going to have to focus!

Thanks again for your time!

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUt
no=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5M
Qa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQ
DJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILS
XzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW
651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZE
MPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D&u=https%3A%
2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

That’s not well defined as there are various grades below that. Is the plan to 
remove any CA that doesn’t comply with this requirement? 

 

From: Ryan Sleevi  
Sent: Friday, December 7, 2018 2:26 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: CA Communication: Underscores in dNSNames

 

 

On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This isn't a CA-issue because the risk associated with non-compliance isn't
defined yet.

 

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

 

""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) 
or remove a certificate at any time and for any reason. This may happen 
immediately or on a planned future date. Mozilla will disable or remove a 
certificate if the CA demonstrates ongoing or egregious practices that do not 
maintain the expected level of service or that do not comply with the 
requirements of this policy.""

 

Sounds like the risk is well-defined and documented.

 

>From what I've heard here, the risk is distrust or loss of EV
indicators, which is distrust-like. That's a pretty big thing to push back
on the CA for a non-security issue.  Thus, I think the risk of missing the
underscore revocation date needs to be discussed here so everyone, including
website operators and the relying parties, know first-hand what the risks of
the CA missing the deadline are. 

 

Any and every qualification or failure to abide by the program requirements 
comes with it the risk of sanction, up to, and including, distrust.

 

It sounds like you're looking for a way for CAs to make a cost/benefit analysis 
as to whether it's more beneficial to them to violate requirements, by having a 
clearer guarantee what it will cost them if they intentionally do so, versus 
what they may gain from their Subscribers. That doesn't really seem aligned 
with the incentives of the ecosystem or the relying parties, since CAs (and 
their Subscribers) are not able to, on purely technical level, evaluate the 
cost or impact to Relying Parties, since Relying Parties include every possible 
entity that trusts that root.

 

If the risk is that there is a note on the
audit, that is an acceptable risk. If the risk is a loss of the
root...probably less so.  Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible.  

 

While I think it's positive and encouraging to see CAs acknowledge that their 
audits exist to disclose non-conformities/qualifications, I don't think it 
should be seen as legitimizing or accepting that intentional 
non-conformities/qualifications are desirable. A well-run CA should strive to 
have zero qualifications, findings, or non-conformities - not because they were 
able to convince their auditor that they weren't issues / were minor, but 
because they operated above and beyond reproach, and there were literally no 
issues. Anything short of that is an indicator that a CA is failing in its role 
as a trusted steward, and repeated failures seem reasonable to discuss sanction 
or distrust. CAs (and their sub-CAs) with a pattern of incidents on the 
incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and 
https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk 
of sanction, given the pre-existing patterns of non-compliance.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

I only ask because telling people to go back to the CA and work something out 
isn’t a great answer when the retort is that the CA will be distrusted if they 
don’t. Either the customer doesn’t replace all their certs and they are made 
non-functional by revocation or the certs are distrusted because the CA isn’t 
operational anymore. Telling people to go have the CA cover the risk when those 
are the two options seems like we’re avoiding the public discussion. 

 

From: Ryan Sleevi  
Sent: Friday, December 7, 2018 2:26 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: CA Communication: Underscores in dNSNames

 

 

On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This isn't a CA-issue because the risk associated with non-compliance isn't
defined yet.

 

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

 

""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) 
or remove a certificate at any time and for any reason. This may happen 
immediately or on a planned future date. Mozilla will disable or remove a 
certificate if the CA demonstrates ongoing or egregious practices that do not 
maintain the expected level of service or that do not comply with the 
requirements of this policy.""

 

Sounds like the risk is well-defined and documented.

 

>From what I've heard here, the risk is distrust or loss of EV
indicators, which is distrust-like. That's a pretty big thing to push back
on the CA for a non-security issue.  Thus, I think the risk of missing the
underscore revocation date needs to be discussed here so everyone, including
website operators and the relying parties, know first-hand what the risks of
the CA missing the deadline are. 

 

Any and every qualification or failure to abide by the program requirements 
comes with it the risk of sanction, up to, and including, distrust.

 

It sounds like you're looking for a way for CAs to make a cost/benefit analysis 
as to whether it's more beneficial to them to violate requirements, by having a 
clearer guarantee what it will cost them if they intentionally do so, versus 
what they may gain from their Subscribers. That doesn't really seem aligned 
with the incentives of the ecosystem or the relying parties, since CAs (and 
their Subscribers) are not able to, on purely technical level, evaluate the 
cost or impact to Relying Parties, since Relying Parties include every possible 
entity that trusts that root.

 

If the risk is that there is a note on the
audit, that is an acceptable risk. If the risk is a loss of the
root...probably less so.  Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible.  

 

While I think it's positive and encouraging to see CAs acknowledge that their 
audits exist to disclose non-conformities/qualifications, I don't think it 
should be seen as legitimizing or accepting that intentional 
non-conformities/qualifications are desirable. A well-run CA should strive to 
have zero qualifications, findings, or non-conformities - not because they were 
able to convince their auditor that they weren't issues / were minor, but 
because they operated above and beyond reproach, and there were literally no 
issues. Anything short of that is an indicator that a CA is failing in its role 
as a trusted steward, and repeated failures seem reasonable to discuss sanction 
or distrust. CAs (and their sub-CAs) with a pattern of incidents on the 
incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and 
https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk 
of sanction, given the pre-existing patterns of non-compliance.



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL private key for *.alipcsec.com embedded in PC client executables

[Jeremy Rowley via dev-security-policy]

I think pretty much every ca will accept a signed file in lieu of an actual 
key. Generally provide the key just means some proof of compromise the ca can 
replicate.

From: dev-security-policy  on 
behalf of Matt Palmer via dev-security-policy 

Sent: Monday, December 10, 2018 11:39:31 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client 
executables

On Tue, Dec 11, 2018 at 05:37:41AM +, Xiaoyin Liu via dev-security-policy 
wrote:
> It’s clear that the private key for *.alipcsec.com is embedded in the
> executable,

There are ways of implementing SSL such that the private key doesn't *have*
to be stored locally.  They all require the TLS termination point to be able
to communicate with the service that *does* hold the private key, so a good
way to test that the key is stored locally is to remove external
connectivity and then try to establish a TLS connection.  If you still can,
the key has to be *somewhere*.

> packed by VMProtect, and the process has anti-debugging protection.  I
> tried plenty of methods to extract the private key, but didn’t succeed.  I
> reported this to Alibaba SRC anyway.  They replied that they ignore this
> issue unless I can successfully extract the key.

That sounds like it might be an admission that the binary *is* in the
executable, and they're just hoping you won't be able to get it.

> So is this a certificate misuse issue, even if the private key is
> obfuscated?  If so, do I have to extract the private key first before the
> CA can revoke the cert?

Sadly, some CAs do indeed require you to *actually* produce the private key
in order for them to consider the key compromised.  Given that people can
pull apart Nation-State grade malware I think "we don't *know* that anyone's
found it yet" is lamentably short-sighted, but absent an explicit rule that
a key is considered compromised if it can be shown that it *must* be in
a local executable, some CAs will continue to stick to their current
standards.

You can see how a similar situation played out in the past, in
https://clicktime.symantec.com/a/1/z7t2f8C-xqcp0GyPdbPYq0AzStbSzZZLsAiWkgf1Qao=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D&u=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2Fpk039T_wPrI%2FtGnFDFTnCQAJ

However, I don't know what GlobalSign's policy is regarding revocation
proof.  Rather than just talking to Alibaba, it would be worth contacting
GlobalSign's problem reporting address (which is listed in the problem
reporting list in the CCADB, at
https://clicktime.symantec.com/a/1/Q235mwJymdbdGiH8YOe0XcXtTxxDAnyPflk1ft55vMI=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D&u=https%3A%2F%2Fccadb-public.secure.force.com%2Fmozilla%2FAllProblemReportingMechanismsReport)
and putting the situation to them.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/0DB1rX6Nb0O0ODt9aZeLn-fDlAWawyUHF7uk_TFf9aU=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Underscore characters and DigiCert

[Jeremy Rowley via dev-security-policy]

Hey all, 

 

We're working towards revoking certs with underscore characters in the
domain name, per SC12, but I had a question about legacy Symantec systems
and Mozilla. These particular roots are no longer trusted for TLS certs in
Google or Mozilla, which means the applicability of the BRs is dubious. The
roots are shortly being removed from Microsoft and Apple, although that's
more of an FYI rather than something with direct bearing on the Mozilla
community. If the roots are no longer trusted for TLS in Mozilla, is there
any requirement to revoke the certs issued under those roots?  

 

My initial thought is no as this is similar to what Comodo did with their
request to remove a SHA1 root (and what DigiCert did with one of the Verizon
roots). Note these are still flagged by zlint because they are trusted in
older systems. Because the situation is slightly different with the way
distrust was technically implemented, I wanted to see if there were any
concerns with the community about treating these as private going forward,
similar to the SHA1 roots.  Thoughts?

 

Jeremy 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

s/MIME certs and authentication

[Jeremy Rowley via dev-security-policy]

Now that the Symantec TLS distrust is essentially behind us, we're working
on migrating all of the s/MIME certificates to DigiCert hierarchies. Once
this is complete, the browsers can remove the legacy Symantec roots
completely. In my new compliance role, I'm looking at how to create a
smooth, but compliant, transition process. One major question I had while
reviewing some of the systems is the frequency of s/MIME cert
reverification. Nothing is specified in the policy that I could see. I
thought I'd raise the question here to see if there's a policy somewhere
else or if Mozilla wants to consider an official policy in one of its next
updates.

 

Some systems look like they verify the email address/domain name at issuance
and then never again for the same account. Other systems verify the email
address and domain every 825 days. The last set verifies the email address
each time a certificate is issued.  I think each are equally compliant, but
the set-it-and-forget it method doesn't seem in the spirit of ensuring
control over the email address. Is there guidance on how often this
reverification should occur?

 

Thanks for the input.

Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Underscore characters and DigiCert

[Jeremy Rowley via dev-security-policy]

Can we request removal of these roots now? This seems very similar to the
SHA1 situation where CAs requested root removal and then treated the root as
private, regardless of the trust in older platforms. 

-Original Message-
From: dev-security-policy  On
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, December 13, 2018 3:11 PM
To: mozilla-dev-security-policy

Subject: Re: Underscore characters and DigiCert

There are currently no program requirements for roots that have had their
websites trust bit turned off or been removed from NSS, but this is an open
area of concern [1]. When a root is disabled or removed, there is no
protection for Firefox users who haven't updated to a current version, nor
for any of the other consumers of our root store until they update.

However, that doesn't apply here. These roots are still in the Mozilla root
store and trusted for TLS, and some of them will be for quite a while due to
the whitelisted Apple & Google intermediates [2]. It is clear that Mozilla
policy, and in-turn the BRs, still apply to these roots.

Should DigiCert decide not to revoke certificates containing underscores by
the 15-Jan deadline in SC12, including those chaining to distrusted Symantec
roots, I plan to treat it as an incident. As with any incident, full
disclosure is the expectation.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/124
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

On Wed, Dec 12, 2018 at 5:54 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey all,
>
> We're working towards revoking certs with underscore characters in the 
> domain name, per SC12, but I had a question about legacy Symantec 
> systems and Mozilla. These particular roots are no longer trusted for 
> TLS certs in Google or Mozilla, which means the applicability of the 
> BRs is dubious. The roots are shortly being removed from Microsoft and 
> Apple, although that's more of an FYI rather than something with 
> direct bearing on the Mozilla community. If the roots are no longer 
> trusted for TLS in Mozilla, is there any requirement to revoke the certs
issued under those roots?
>
>
>
> My initial thought is no as this is similar to what Comodo did with 
> their request to remove a SHA1 root (and what DigiCert did with one of 
> the Verizon roots). Note these are still flagged by zlint because they 
> are trusted in older systems. Because the situation is slightly 
> different with the way distrust was technically implemented, I wanted 
> to see if there were any concerns with the community about treating 
> these as private going forward, similar to the SHA1 roots.  Thoughts?
>
>
>
> Jeremy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: s/MIME certs and authentication

[Jeremy Rowley via dev-security-policy]

This is one of the reasons I wanted to raise the issue. Issuing the cert and
delivering to the email seems like a pretty common way to verify email certs
(either you have access to the email or you don't), but this is backwards
from TLS. Is this particular process a violation of the Mozilla policy?

Mozilla policy, Section 2.2 #2:
"For a certificate capable of being used for digitally signing or encrypting
email messages, the CA takes reasonable measures to verify that the entity
submitting the request controls the email account associated with the email
address referenced in the certificate or has been authorized by the email
account holder to act on the account holder's behalf. The CA's CP/CPS must
clearly specify the procedure(s) that the CA employs to perform this
verification."

There's nothing that specifies the cert must be issued after the verifying
control or that issuance can't be part of the verification process. Although
this seems backwards, I still think it's compliant with the Mozilla policy. 


-Original Message-
From: dev-security-policy  On
Behalf Of Matt Palmer via dev-security-policy
Sent: Thursday, December 13, 2018 2:39 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: s/MIME certs and authentication

On Thu, Dec 13, 2018 at 09:50:21AM -0800, pedro.wisekey--- via
dev-security-policy wrote:
> For S/MIME capability itself, we are required to ensure that "the 
> entity submitting the request controls the email account associated 
> with the email address referenced in the certificate", so by merely 
> making the process to require the user to access his email account to, 
> for example, download the renewed certificate it seems to be enough, 
> as any other method like a bounce-back message could probably get to the
same result.

That seems rather backwards.  You're issuing the certificate and *then*
validating control of the e-mail address.  I doubt that issuing a TLS server
certificate and then performing domain control validation would be
considered acceptable, and I don't imagine there's enough of a difference in
S/MIME certificates to make it acceptable for those, either.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert Assured ID Root CA and Global Root CA EV Request

[Jeremy Rowley via dev-security-policy]

* The TERENA SSL CA 3 subordinate has misissued a number of certificates [3], 
most of which are not revoked. 

- We can revoke these. I have no issue remediating them.  I didn’t realize 
these were an ongoing concern. 

 

*  DigiCert’s response in this bug states “We were under the impression from 
previous communications with Mozilla that certain types of errors identified 
did not require certificate revocation. It would help if Mozilla could indicate 
which certificate errors are believed to require revocation. We will then 
review the lists to see which certificates need to be revoked.” I do not 
believe that Mozilla should create such a list, and we have set a precedent for 
requiring revocation for at least some of the errors that are identified - e.g. 
metadata in subject fields [4].

- That’s fine, but the answer still stands as why we didn’t revoke them before. 
Gerv told us we didn’t need to revoke them because they didn’t represent an 
actual security concern. I can go find the email if that helps.


* In addition, DigiCert previously reported that they had addressed the problem 
of metadata in subject fields for certificates issued by the Terena subordinate 
[5].

- Yes. This should be addressed. Unless you are expecting them to be revoked 
now? 



* Linters identify a large number of misissued certificates under the DigiCert 
SHA2 Secure Server CA intermediate [6]. Many of these are false positives (e.g. 
ZLint expects CN and SAN fields to be lowercased), but some are not and of 
those many are not revoked - e.g. [7].


Thanks a ton for the breakdown. We’ll get these taken care of where it’s not a 
false positive. I think there are only 2-3 that are not false positives, with 2 
not previously discussed. 

 

Here’s the breakdown:


   FATAL: x509: RSA modulus is not a positive number 



Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 
2^256-1. The team implementing this thought saw SHOULD and thought it was 
optional. They missed the sentence before which says the public exponent MUST 
be equal to 3 or more. I’ll file and incident report on this.

 

 


   FATAL: asn1: structure error: integer not minimally-encoded 

 


I think this one is a false positive? It’s caused by padded zeros which  aren’t 
expressly prohibited. Want us to revoke these?

 

 


 ERROR: The common name field in subscriber certificates must include only 
names from the SAN extension 

This one is a false positive

 

ERROR: DNSNames must have a valid TLD

This is a false positive

 

ERROR: The 'Organization Name' field of the subject MUST be less than 64 
characters

This is one of the issues mentioned above. We can revoke all of these. We 
didn’t know Mozilla was waiting on that.

 


 

ERROR: CAs MUST NOT issue subscriber certificates with validity periods longer 
than 39 months regardless of circumstance.

False positive

 

 ERROR: The country name field MUST contain the two-letter ISO code for the 
country or XX 

Grr.. I dislike this one (XK was used instead of XX). Although recognized as a 
temporary code for Kosovo, technically XK is not an official ISO code so it 
violates the strict letter of the law. We’ll revoke these.

 

ERROR: Subject name fields must not contain '.','-',' ' or any other indication 
that the field has been omitted 

False positive. The BRs say “All other optional attributes, when present within 
the subject field, MUST contain information that has  been verified by the CA. 
Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. 
space)  characters, and/or any other indication that the value is absent, 
incomplete, or not applicable.” With the strict wording policy that seems in 
effect, organizationalUnit is not “All other optional attributes”. It’s a 
defined attribute and thus cannot be “other”.

 

ERROR: Explicit text has a maximum size of 200 characters

False positive I think…. 

 

 


ERROR: Subscriber Certificates issued after 1 July 2016 but prior to 1 March 
2018 MUST have a Validity Period no greater than 39 months. 

 


False positive

 

 ERROR: Subscriber Certificate: subject:localityName MUST appear if 
subject:organizationName, subject:givenName, or subject:surname fields are 
present but the subject:stateOrProvinceName field is absent. 

 


Wow. I hadn’t seen this. It’ll be revoked and we’ll look at what happened.

 

 

* CPS section 3.2.2 did not, in my opinion, adequately specify the procedures 
employed to perform email address verification as required by Mozilla policy 
section 2.2(2). The latest update addressed this.
- This is an issue related to the fact there is no policy on s/MIME. We updated 
it with more specificity, of course, but I’d love to see a real s/MIME policy.

 

Thanks Wayne. I can confirm we will revoke all mis-issued certs.

 

 

From: Wayne Thayer  
Sent: Thursday, December 13, 2018 5:34 PM
To: Jeremy Rowley 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 

Subject: Re: DigiCert