Chunghwa Telecom eCA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

This request is for inclusion of the Chunghwa Telecom eCA as documented in
the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1341604

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8963172

* Summary of Information Gathered and Verified:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8960397

* Root Certificate Download URL: http://eca.hinet.net/download/eCA2.cer

* CP/CPS:
** Root CP: http://eca.hinet.net/download/ePKI_CP_v1.5(Eng).pdf
** Root CPS: https://bug1341604.bmoattachments.org/attachment.cgi?id=8961804
** Public (DV, OV) intermediate CPS:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8961805
** EV intermediate CPS:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8961812

* This request is to turn on the Websites and Email trust bits. EV
treatment is requested.

* EV Policy OID: 2.23.140.1.1

* Test Websites:
** Valid: https://ev.hinet.net/
** Expired: https://ra.testev.hinet.net/
** Revoked: https://testev.hinet.net/

* CRL URL: http://repository.ev.hinet.net/crl/EVSSL/complete.crl

* OCSP URL: http://ocsp.ev.hinet.net/OCSP/ocsp

* Audit: Annual audits are performed by SunRise CPAs / DFK International
according to the WebTrust for CA, BR, and EV audit criteria.
** WebTrust: https://cert.webtrust.org/SealFile?seal=2306=pdf
** BR: https://cert.webtrust.org/SealFile?seal=2307=pdf
** EV: https://cert.webtrust.org/SealFile?seal=2279=pdf

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Chunghwa Telecom eCA inclusion request that is being tracked in this bug
and have the following comments:

==Good==
* Clean WebTrust & BR audit statements cover periods back to the creation
of this root in 2015.
* The CPSs properly document 825 day maximum validity periods, and change
logs were recently added.

==Meh==
* Both of the domain validation methods that will be deprecated on 1-August
are currently listed as in-use in the root CP/CPS
* CAA Issuer Domain Names are only specified in the root CP, in section
1.3.2.2 rather than 2.2.
* For domain validation, each CPS does not state which subsection of BR
3.2.2.4 it is complying with as recommended by our policy.
* There is, in my opinion, an excessive amount of duplication of
information between the CP and 3 CPSs (over 600 pages in total), making the
review of these docs difficult and tedious.

==Bad==
* A large number of certificates have been misissued from the “Public
Certification Authority - G2” intermediate [4] (recent example: [2]). Many
of these certificates remain valid. Chunghwa Telecom has published a
response to these errors [3] in the inclusion bug. My main concern with the
response is the assertion that some of these are not SSL certificates bound
to follow the BRs because they do not contain the CAB Forum OV OID in the
certificate policies extension. This assertion contradicts section 1.1 of
Mozilla policy.

This begins the 3-week comment period for this request [4].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

- Wayne

[1]
https://crt.sh/?CAID=1770=cablint,zlint,x509lint=2015-01-01
[2] https://crt.sh/?id=290793483=zlint,cablint,x509lint
[3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418
[4] https://wiki.mozilla.org/CA/Application_Process
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

I have incorporated the final changes from our policy discussions, as well
as some corrections and clarifications that Kathleen and I found during our
review, into the latest draft of the policy:
https://github.com/mozilla/pkipolicy/compare/master...2.6 I would encourage
everyone to review the changes and respond with any comments.

On Fri, May 11, 2018 at 11:11 AM Wayne Thayer  wrote:

> We're concluding discussions on all of the issues identified for version
> 2.6 of the policy [1].
>
> You can find a complete set of changes here:
> https://github.com/mozilla/pkipolicy/compare/master...2.6
>
> Two of the changes [2][3] require CAs to update their CP/CPS. For many CAs
> the current practice is to wait for the next required annual review
> (usually coinciding with their audit) to make CP/CPS changes. Do we want to
> allow that practice to continue, or set a date by which we expect CP/CPSs
> to reflect the new requirements? This was previously discussed [4], with
> the outcome being that we would make these decisions on a case-by-case
> basis.
>
> >
Since there were no comments on the question above, we'll continue with the
status-quo: there will be no defined enforcement date for the CP/CPS
changes required by the 2.6 version of our policy. CAs are expected to
update their CP/CPSs within a reasonable period of time of the 2.6
effective date. I expect the 2.6 effective date to be sometime in June.
>

> - Wayne
>
> [1]
> https://github.com/mozilla/pkipolicy/issues?utf8=%E2%9C%93=label%3A2.6+
> [2]
> https://github.com/mozilla/pkipolicy/commit/e5269ff0d6ced93a6c6af65947712b8e4b2e18b8
> [3]
> https://github.com/mozilla/pkipolicy/commit/42ebde18794bc1690885bfdd4e3fb12e7c2c832b
> [4]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/TT2u4wfoBQAJ
>
> On Mon, Mar 19, 2018 at 10:15 PM Wayne Thayer  wrote:
>
>> There are 17 proposed changes in total for version 2.6 of the policy, and
>> I'm about to kick off discussions on the first batch. I expect some of
>> these to be straightforward while others will hopefully generate good
>> dialogues. As always, everyone's constructive input is appreciated.
>>
>> Thanks,
>>
>> Wayne
>>
>> On Wed, Feb 21, 2018 at 9:14 AM, Wayne Thayer 
>> wrote:
>>
>>> I've added the issue of subordinate CA transfers to the list for policy
>>> version 2.6: https://github.com/mozilla/pkipolicy/issues/122
>>>
>>>
>>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[jacob.hoffmanandrews--- via dev-security-policy]

On Friday, May 18, 2018 at 10:52:25 AM UTC-7, Tim Hollebeek wrote:
> > Our logging of the CAA records processed does not provide the case
> > information we need to determine whether other issuances were affected by
> > this bug.
> 
> We put a requirement in the BRs specifically so this problem could not occur:
> 
> "The CA SHALL log all actions taken, if any, consistent with its processing 
> practice."

To be clear, we do log every CAA lookup 
(https://github.com/letsencrypt/boulder/blob/master/va/caa.go#L47). However, we 
do it at too high a level of abstraction: It doesn't contain the unprocessed 
return values from DNS. We plan to improve that as part of our remediation.

Our ideal would be to log all DNS traffic associated with each issuance, 
including A, , TXT, and CAA lookups. We initially experimented with this by 
capturing the full verbose output from our recursive resolver, but concluded 
that it was not usable for investigations because it was not possible to 
associate specific query/response pairs with the validation request that caused 
them (for instance, consider NS referrals, CNAME indirection, and caching). I 
think this is definitely an area of improvement we could pursue in the DNS 
ecosystem that would be particularly beneficial for CAs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Incident Report - Domain validation by CNAME with omitted underscore

[Robin Alden via dev-security-policy]

This same information has also been posted to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1461391

Andrew Ayer reported this problem report to mailto:sslab...@comodoca.com:

<<<
I was able to obtain a certificate from Comodo that was not properly
validated under the Baseline Requirements, as follows:

1. Visit https://www.positivessl.com/ and click "Try Now" under "Free SSL 
Certificate".

2. Provide a CSR for the FQDN dcv.party.

3. On the next page, select "CNAME CSR Hash 2" as the method of Domain Control 
Validation.

4. Publish the following DNS record:
ae104fe977c36b235260d331c949b8ca.dcv.party. CNAME 
7b4c2cd1009045dc12d3e8b0c3d02912.406b5877e3a9f1eda4b7d8253ac1eb18.comodoca.com.

5. Complete the form and submit the order.

6. Receive a valid certificate for dcv.party and www.dcv.party (attached).

Section 3.2.2.4.7 ("DNS Change") of the BRs says:

"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 
1) an Authorization Domain Name; or 
2) an Authorization Domain Name that is prefixed with a label that begins with 
an underscore character."

Since ae104fe977c36b235260d331c949b8ca.dcv.party is not an Authorization Domain 
Name for (www.)dcv.party, nor is it an Authorization Domain Name that is 
prefixed with a label that begins with an underscore character, this 
certificate was not properly validated.
>>>

Incident report:

1) How Comodo CA first became aware of the problem
We were informed by an email from Andrew Ayer to our abuse email address 
mailto:sslab...@comodoca.com at 18:50 BST (UTC + 1) on Monday 14th May.

2) A timeline of the actions Comodo CA took in response. 

2017 July 11 - We introduced our new implementations of DCV methods designed to 
meet the requirements of the CA/B Forums BR's version 1.4.1 section 3.2.2.4, as 
required by Mozilla.
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationSurveySample?CACommunicationId=a05o03WrzBC
(See Action #1 in that link)

2017 July 13 - We reviewed version 1.4.1 of the BRs along with the then 
in-process ballots in the CA/B Forum.
We determined that the underscore at the start of the CNAME LValue in 3.2.2.4.7 
was optional.  This now appears to have been a mistake.

2017 July 20 - We withdrew our old DCV methods that consciously relied on the 
'Any Other Method'. 

2017 July 20 - In response to complaints from some EU operators who found that 
their DNS web portals would not let them specify a leading underscore in a 
CNAME LValue, we introduced a new DCV variant that permitted the underscore to 
be omitted.

2018 May 14 - Initial problem report received from Andrew Ayer.

2018 May 15 - Code changes prepared to remove the option for the leading 
underscore to be omitted from the CNAME LValue in 3.2.2.4.7 domain validation.
QA begins.

2018 May 18 17:20 (UTC+1) - QA completed.  Code released to live.  No further 
domains will be validated using the flawed method.

3) A summary of the problematic certificates. 
A total of 11099 TLS/SSL certificates were issued that used the variant of 
3.2.2.4.7 that omitted the leading underscore.
The earliest such certificate was issued on 2017 July 20.
10993 of those TLS/SSL certificates remain unexpired and unrevoked.

4) The complete certificate data for the problematic certificates. 
This is a list of all of the unexpired certificates:
https://docs.google.com/spreadsheets/d/1ZW-YdrjeoUsMpTY0CW3f2D59Bl188K398oda7qTUM1Q/edit?usp=sharing

5) How and why we came to issue these certificates
When implemented code to remove our reliance on the old 'Any other method' 
domain validation section 3.2.2.4.11 in May, June, and July 2017, the 
then-current version of the BRs did not actually contain any of the new DCV 
methods.  Mozilla had requested compliance with 3.2.2.4 from version 1.4.1 
which was issued in September 2016.  That version including the 'blessed' 
methods - albeit somewhat out of date.
In 2017 July we misinterpreted the words 
"for an Authorization Domain Name 
  or an Authorization Domain Name that is prefixed with a label that begins 
with an underscore character" to mean
"for an Authorization Domain Name prefixed with a label 
  or an Authorization Domain Name that is prefixed with a label that begins 
with an underscore character".
With hindsight we agree that this interpretation of the BRs was incorrect.

We added the variant of 3.2.2.4.7 without the underscore in response to 
customer requests and mistakenly believed it to be a permitted variation when 
we implemented it.

Our implementation of 3.2.2.4.7 (with or without underscore) has always 
required that a request-specific label is prefixed to the Authorization Domain 
Name as part of the Request Token.
Our syntax for constructing the CNAME to pass validation is documented in
https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf, but 
in brief is this:
"When using DNS CNAME 

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[Tim Hollebeek via dev-security-policy]

> Our logging of the CAA records processed does not provide the case
> information we need to determine whether other issuances were affected by
> this bug.

We put a requirement in the BRs specifically so this problem could not occur:

"The CA SHALL log all actions taken, if any, consistent with its processing 
practice."

-Tim


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: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[Jonathan Rudenberg via dev-security-policy]

Oops, I missed item 1, disregard :)

On Fri, May 18, 2018, at 13:45, Jonathan Rudenberg via dev-security-policy 
wrote:
> On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote:
> > 2. Performing a scan of current CAA records for the domain names we have 
> > issued for in the past 90 days, specifically looking for tags in CAA 
> > records with non-lowercase characters. We’ll examine such instances on a 
> > case-by-case basis to determine the appropriate action.
> 
> Do you log the full CAA record set (if any) for each authorized domain? 
> If so, can you use those instead of the "current" records to find 
> potentially unauthorized issuance?
> ___
> 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: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[Jonathan Rudenberg via dev-security-policy]

On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote:
> 2. Performing a scan of current CAA records for the domain names we have 
> issued for in the past 90 days, specifically looking for tags in CAA 
> records with non-lowercase characters. We’ll examine such instances on a 
> case-by-case basis to determine the appropriate action.

Do you log the full CAA record set (if any) for each authorized domain? If so, 
can you use those instead of the "current" records to find potentially 
unauthorized issuance?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[josh--- via dev-security-policy]

At 12:45 UTC we received a report to our cert-prob-repo...@letsencrypt.org 
contact address that Let’s Encrypt was improperly handling CAA records with 
mixed case tags, resulting in mis-issuance under the baseline requirements. 
Thanks to Corey Bonnell of TrustWave for the report.

RFC 6844 Section 5.1[0] says: “Matching of tag values is case insensitive.” 
Let’s Encrypt’s implementation of CAA record processing processed CAA tags case 
sensitively[1]. This led to CAA tags that were not lowercase being ignored 
during CAA validation.

The problem was quickly confirmed, and a fix was developed and reviewed[2], 
with tests, by 13:28 UTC - under an hour from the initial report. We deployed 
the fix to our staging environment at 14:37 UTC. We disabled issuance of new 
certificates in our production environment at 14:45 UTC, to prevent additional 
misissuance from occurring. We deployed the fix to our production environment 
at 15:20 UTC.

Our logging of the CAA records processed does not provide the case information 
we need to determine whether other issuances were affected by this bug. We plan 
to perform these two post-incident remediation items to start with:

1. Improving the CAA validation logging in Boulder[3] to log CAA records prior 
to our processing.

2. Performing a scan of current CAA records for the domain names we have issued 
for in the past 90 days, specifically looking for tags in CAA records with 
non-lowercase characters. We’ll examine such instances on a case-by-case basis 
to determine the appropriate action.

The original reporter identified one certificate (https://crt.sh/?id=469407542) 
that was issued in violation of the CAA RFC as part of their testing. We have 
revoked this certificate as of 15:41 UTC.

[0] - https://tools.ietf.org/html/rfc6844#section-5.1

[1] - 
https://github.com/letsencrypt/boulder/blob/9990d14654661736a6ee6dc1520f605d0896c72d/va/caa.go#L82-L100

[2] - https://github.com/letsencrypt/boulder/pull/3722

[3] - https://github.com/letsencrypt/boulder/issues/3724
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy