Re: TURKTRUST Non-compliance

[Jakob Bohm via dev-security-policy]

On 17/03/2018 01:23, Wayne Thayer wrote:

TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
root included in the Mozilla program with the 'websites' trust bit enabled
(not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1],
and 13 unexpired end-entity certificates signed by this root [2]. The
audits for this root are either already expired (based on audit date) or
nearly expired (based on the ETSI certificate expiration date) [3] [4].



Note that 3 of those certificates are CA operational certificates, such
as for the required test URLs.  Thus only 10 true end certificates
remain, all of which will expire in less than 12 months (last two expire
2019-03-18).


TURKTRUST announced the suspension of their SSL business in 2016 [5].

TURKTRUST failed to respond to the January 2018 CA Communication. After
repeated attempts, they did respond to my emails and posted a statement in
the bug [6] including the following:

The strategic decision mentioned above is actually suspending all SSL

business supporting activities that incur direct costs for TURKTRUST,
including suspending the ETSI and BR audits or OV and EV SSL related
insurance policies. We have also ceased our investment and studies on CT
and CAA requirements for the time being that are actually mandatory
criteria set by the CA/Browser Forum.





Note, that if it is reasonably certain/validated that the only activity
is maintaining CRLs/OCSP for the remaining unexpired certificates, then
most of the updated BR requirements (such as CAA, CT and stricter
validation methods) become noops, since no validations are being done,
no CAA strings are accepted, no new certificates are issued etc.

We may thus be looking at the 12 months of an orderly shutdown of a
CA, as per section 5.8 of the standard CPS template, and might
reasonably consider accepting the lack of normal activity levels for
such a situation.  The BRs and Mozilla policy seem silent on the
subject,

The only critical thing that seems to be missing is a BR audit report to
confirm that no issuance is taking place and the revocation management
and CA private key protection is still being done properly.



TURKTRUST has chosen not to request removal of the root, but I believe this
is a clear case in which prompt removal of the root is necessary.

I would appreciate everyone's constructive input on what action should be
taken.

- Wayne

[1] https://crt.sh/?Identity=%25=5766=expired
[2] https://crt.sh/?Identity=%25=5767=expired

[3] https://bug1332435.bmoattachments.org/attachment.cgi?id=8828490
[4]
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/6749UE_s.pdf

[5] https://cabforum.org/pipermail/public/2016-September/008475.html

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1439127




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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

Policy 2.6 Proposal: Update domain validation requirements

[Wayne Thayer via dev-security-policy]

Section 2.2(3) defines very specific requirements for use of the BR 3.2.2.4
domain validation methods. Now that 3.2.2.4.11 (“any other method”) has
been removed from the BRs and ballot 218 [1] has passed, the Mozilla policy
is out-of-date. I propose the following changes:

* Remove the reference to BR version 1.4.1 and instead require compliance
with the current version. With the adoption of ballot 190 [2], the
reference to version 1.4.1 is no longer needed.
* Remove the reference to "10" methods, since the number is likely to
change.
* Add a new bullet on IP Address validation that forbids the use of BR
3.2.2.5(4) (“any other method”) and requires disclosure of IP Address
validation processes in the CA’s CP/CPS.
* Add the following language:

> Validation methods are occasionally found to contain security flaws. If
> this happens, Mozilla will communicate to CAs any disclosures or
> modifications it requires, up to and including discontinuing use of a
> method immediately.
>

I have intentionally not proposed a ban on methods 3.2.2.4.9 and 3.2.2.4.10
at this time. Work is underway in the IETF to fix method 10 [3], and I
suspect that the fix will be permitted under the existing 3.2.2.4.10
language. I’m proposing that we not make the use of any improved versions
of method 9 or 10 contingent on an update to our policy or on a BR change
that creates a new method number.

This is:
https://github.com/mozilla/pkipolicy/issues/121
https://github.com/mozilla/pkipolicy/issues/116
https://github.com/mozilla/pkipolicy/issues/115

[1] https://cabforum.org/2018/02/05/ballot-218-remove-
validation-methods-1-5/
[2] https://cabforum.org/2017/09/19/ballot-190-revised-
validation-requirements/
[3] https://datatracker.ietf.org/doc/draft-ietf-acme-tls-alpn/
---

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

Policy 2.6 Proposal: Move Compliance Date into policy

[Wayne Thayer via dev-security-policy]

Historically, the effective dates of new versions of the policy have been
maintained separately from the policy itself [1]. In our November
Communication, we learned that many CAs weren’t in compliance with policy
version 2.5 despite it having been in effect since June [2]. This proposal
is simply to add the Compliance Date to the policy itself, below the
version number, to make it more visible.

In addition, I propose that we adopt the norm of setting the Compliance
Date to 2 months after the Publication Date, to make it clearer that CAs
are expected to implement whatever changes are necessary no later than the
Compliance Date. This norm would not affect our ability to define more
specific Compliance Dates for specific changes to the policy.

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

[1] https://wiki.mozilla.org/CA/Root_Store_Policy_Archive
[2] https://groups.google.com/d/msg/mozilla.dev.security.policy/Bs3yRryKWFQ/
zJkUtz0GBAAJ

---

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

Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

[Wayne Thayer via dev-security-policy]

A few months ago, we discussed our root inclusion criteria [1], and came to
a conclusion that I summarized and proposed in policy as follows:

I would like to thank everyone for your constructive input on this topic.
> At the outset I stated a desire to ‘establish some objective criteria that
> can be measured and applied fairly’. While some suggestions have been made,
> no clear set of criteria has emerged. At the same time, we’ve heard the
> argument that our time would be better spent on raising the bar for all CAs
> in the program, regardless of their subjective value to typical users of
> our products.
>
> Some thought was also given to applying unique technical criteria to new
> CAs, such as limiting certificate lifetime to 90 days or requiring ACME
> support. It was pointed out, however, that this favors incumbents and
> doesn’t drive improvement in the overall ecosystem.
>
> The conclusion from this discussion is that we will not attempt to restrict
> organizations from participating in the Mozilla CA program based on a
> judgement of their value to our users. We will continue to require
> applicants to demonstrate compliance with our policies, and reserve the
> right to deny membership to any CA at our discretion, e.g. because they
> have a documented pattern of misbehavior or we believe they intend to
> violate our policies.
>
> Here is a proposed update to the Mozilla Root Store Policy reflecting this
> decision:
>
> https://github.com/mozilla/pkipolicy/compare/master...
> inclusion-criteria?quick_pull=1
>

Having just reviewed this again, I recommend that we also remove the word
“typical” from section 2.1(1) of the policy that reads:

CAs whose certificates are included in Mozilla's root program MUST:
> 1. provide some service relevant to typical users of our software
> products;
>

This is: https://github.com/mozilla/pkipolicy/issues/118 and
https://github.com/mozilla/pkipolicy/issues/104

[1] https://groups.google.com/d/msg/mozilla.dev.security.
policy/GbXvh9ulboI/DWdJUc_cAQAJ

---

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

Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

[Wayne Thayer via dev-security-policy]

This new version of the policy won’t be completed until after 15-April,
which is the revised deadline for disclosure and auditing of unconstrained
email subordinates. I propose removal of the following exception from
section 5.3.1:

Instead of complying with the above paragraph, intermediate certificates
> issued before 22nd June 2017 may, until 15th January 2018, comply with the
> following paragraph:
>
> If the certificate includes the id-kp-emailProtection extended key usage,
> then all end-entity certificates MUST only include e-mail addresses or
> mailboxes that the issuing CA has confirmed (via technical and/or business
> controls) that the subordinate CA is authorized to use.
>

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

---

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

Re: Root Store Policy 2.6

[Wayne Thayer via dev-security-policy]

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