Drafting Q1 2016 CA Communication

[Kathleen Wilson]

All,

I would like to start drafting the next CA Communication, with the goal
of sending it around the end of February.

For reference, previous CA Communications are here:
https://wiki.mozilla.org/CA:Communications

I think the following items should be in this upcoming communication.
~~
- Have CAs check their included roots, and let us know which of their
roots may be removed (and when). They can do this via Salesforce or via
the reports generated by Salesforce -
https://wiki.mozilla.org/CA:IncludedCAs

- SHA-1 -- CAs need to check their and their subCA systems and put
safeguards in place to ensure they cannot issue SHA-1 SSL/TLS certs
chaining up to their included root certs.

- mozpkix - Things for CAs to Fix
(https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix)
status update
-- Notice of previously allowed certs that are going to break in Firefox
49 if the CA hasn't fixed them -- such certs will be rejected.
https://wiki.mozilla.org/SecurityEngineering/Removing_Compatibility_Workarounds_in_mozilla::pkix

- Rules about testing and test certs (per Symantec incident)
-- What sorts of things do we want to make sure CAs do and don't do
regarding testing?

- CA Community in Salesforce
-- https://wiki.mozilla.org/CA:SalesforceCommunity
-- Need all non-technically-constrained intermediate certs chaining up
to included root certs to be entered into Salesforce by <TBD>.
-- Need all revoked (non-expired) intermediate certs chaining up to
included root certs to be entered into Salesforce by <TBD>.
-- We will expect CAs to continue to update Salesforce as their CA
hierarchies change. This notice is to set some reasonable goals about
when to get the initial data entered.

- Progress on updating Mozilla's CA Certificate Policy
https://wiki.mozilla.org/CA:CertificatePolicyV2.3
[Note to you all: My apologies for letting the policy update discussions
stall. I am hoping to get back to them soon.]
~~

As always, I will appreciate your thoughtful and constructive feedback
on this.

Thanks,
Kathleen

[kwi...@mozilla.com]

On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote:
> All,
>
> I would like to start drafting the next CA Communication, with the goal
> of sending it around the end of February.
>
> For reference, previous CA Communications are here:
> https://wiki.mozilla.org/CA:Communications
>

I will greatly appreciate your feedback on the following draft of the March 2016 CA Communication.
Are the appropriate topics covered?
Are the questions and available responses clear and sufficient?
Do you have suggestions about when the 'TBD' dates should be?
Any other thoughtful and constructive feedback on this will also be appreciated.

I delayed the CA Communication in order to add further customization to the CA Community in Salesforce that will enhance how the communication and survey responses are done. CAs will respond to this communication by logging in to the CA Community in Salesforce.

To view the draft of the March 2016 CA Communication as it will appear for each CA in Salesforce, please browse to
https://wiki.mozilla.org/CA:Communications#March_2016
and click on "Link to DRAFT of March 2016 CA Communication"

The differences between this page and what the CA will see in the CA Community in Saleforce are:
- The date picker fields, check boxes, and text entry fields are not clickable/editable.
- There is no 'Submit' button at the bottom of the page.

For your convenience I have copy-and-pasted the text from that page below.

~~~
March 2016 CA Communication

Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program by [DATE TBD].

To respond to this survey, please login to the CA Community in Salesforce, click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA Communication' survey. Please enter your initial response by [DATE TBD]. After that, you may update your responses until the survey Expiration Date of [TBD], by following these same steps.

A compiled list of CA responses to the survey action items will be automatically published.

In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements. Your contributions to the discussions will help shape the future of Mozilla's CA Certificate Program.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,

Kathleen Wilson
Mozilla CA Program Manager

ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. Check your systems and those of your subordinate CAs to ensure that SHA-1 certificates chaining up to your included root certificates are no longer being issued. Please enter the last date that a SHA-1 certificate was issued that chained up to your root certificate(s) included in Mozilla's program. (Required)


ACTION #1b: Enter the date when all of the SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program will either expire or be revoked. As previously communicated we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. (Required)


ACTION #1c: Enter the date by which safeguards will be put into place that will prevent the future issuance of SHA-1 certificates that chain up to your root certificate(s) included in Mozilla's CA Certificate Program. If you have already completed this, then please enter the approximate date when those safeguards were completed. (Required)


ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the requirement that CAs must provide public-facing documentation about certificate verification requirements and annual public attestation of conformance to the stated certificate verification requirements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy.

Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the PEM data, CP/CPS, and audit statements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. This includes every intermediate certificate (chaining up to your root certificates in Mozilla's program with the Websites trust bit enabled) that is not Technically Constrained via Extended Key Usage and Name Constraint settings.

The date that you enter must be on or before [DATE TBD]. (Required)


ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser.

Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy.

The date that you enter must be on or before [DATE TBD]. (Required)


ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI, we plan to remove these workarounds in Firefox 49. This means that if a certificate has a notBefore date after May 31, 2016, and is affected by any of these workarounds (see below), it will not validate successfully in Firefox 49.

The purpose of this question is to identify interoperability problems that may arise when we make the planned code changes, so we will appreciate your diligence in investigating your certificate issuance practices and previously issued certificates before you respond to this question.

Please select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that will be valid after the release of Firefox 49 in September 2016.

The Bug Numbers below refer to Bugzilla Bugs. (Required)

- id-Netscape-stepUp in Extended Key Usage extension instead of id-kp-serverAuth. Workaround to be removed in Bug #982932.
- DER: default value of OPTIONAL BOOLEAN explicitly encoded. Workaround to be removed in Bug #989518.
- DER: pathLenConstraint included when cA:False. Workaround to be removed in Bug #985025.
- Use of subject CN for naming information. Workaround to be removed in Bug #1245280.
- Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #[TBD].
- nameConstraints/subjectAlternativeName encoding mismatches. Workaround to be removed in Bug #[TBD].
- Empty SEQUENCE in OCSP responses. Workaround to be removed in Bug #[TBD].
- keyUsage lacking keyEncipherment for certs with RSA keys. Workaround to be removed in Bug #[TBD].
- None of the above

ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, when the last of those certificates were issued, and when the last of those certificates expire.


ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know which of your root certificates may be removed, and when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Issuer Field and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed. (Required)


ACTION #6: All certificates that directly or transitively chain to your root certificate(s) included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates.

Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.

[TBD]
What else should we say here?
-- What sort of responses to we want from CAs?
-- Rules about testing and test certs (per Symantec incident)
-- What sorts of things do we want to make sure CAs do and don't do regarding testing? (Required)

~~~ END

As always, I will appreciate your thoughtful and constructive feedback.

Thanks,
Kathleen

[Jakob Bohm]

Does this also apply to "pure ASCII" fields such as country ("C=US")
etc.? Some of those were historically constrained to one of the
lesser ASN.1 string types.

> - nameConstraints/subjectAlternativeName encoding mismatches. Workaround to be removed in Bug #[TBD].
> - Empty SEQUENCE in OCSP responses. Workaround to be removed in Bug #[TBD].
> - keyUsage lacking keyEncipherment for certs with RSA keys. Workaround to be removed in Bug #[TBD].
> - None of the above
>
> ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, when the last of those certificates were issued, and when the last of those certificates expire.
>
>
> ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know which of your root certificates may be removed, and when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Issuer Field and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed. (Required)
>
>
> ACTION #6: All certificates that directly or transitively chain to your root certificate(s) included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates.
>
> Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates.
>
> [TBD]
> What else should we say here?
> -- What sort of responses to we want from CAs?
> -- Rules about testing and test certs (per Symantec incident)
> -- What sorts of things do we want to make sure CAs do and don't do regarding testing? (Required)
>
> ~~~ END
>
> As always, I will appreciate your thoughtful and constructive feedback.
>
> Thanks,
> Kathleen
>
>
>

General: Throughout this document you use phrases such as "all

certificates that directly or transitively chain to your root

certificate(s) included in Mozilla's CA Certificate Program",
shouldn't those phrases exclude technically constrained subCAs,
such as subCAs used exclusively for codesigning (which has a near
indefinite need for SHA-1 certs due to Microsoft actions).


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

[Eric Mill]

Hi Kathleen,

Would this be a good opportunity to ask CAs to do an audit of any
undisclosed cross-signatures they may have to other unconstrained roots?

For example, there were two recently discovered cross-signatures to the
Federal Bridge by commercial CAs, Identrust and Symantec. Once it was
identified that Identrust had not disclosed this cross-signature, Identrust
revoked it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c26

While services like censys.io and crt.sh are doing wonders for finding
things like this, it would also be beneficial to have CAs use their own
vantage point over their cross-signatures to identify other possible gaps
between what Mozilla understands their root store to trust and what it
could potentially be made to trust.

-- Eric

On Thu, Mar 10, 2016 at 6:43 PM, <kwi...@mozilla.com> wrote:

> On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote:

> > All,
> >
> > I would like to start drafting the next CA Communication, with the goal
> > of sending it around the end of February.
> >
> > For reference, previous CA Communications are here:
> > https://wiki.mozilla.org/CA:Communications
> >
>
>

> -- Rules about testing and test certs (per Symantec incident)

> -- What sorts of things do we want to make sure CAs do and don't do

> regarding testing? (Required)
>
> ~~~ END
>
> As always, I will appreciate your thoughtful and constructive feedback.
>
> Thanks,
> Kathleen
>
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Kurt Roeckx]

On 2016-03-11 01:14, Jakob Bohm wrote:
>> - Non-PrintableString/UTF8String in DNs. Workaround to be removed in
>> Bug #[TBD].
>
> Does this also apply to "pure ASCII" fields such as country ("C=US")
> etc.? Some of those were historically constrained to one of the
> lesser ASN.1 string types.

I think C is only a PrintableString, while at least some Turkish CA has
that as an UTF8String. It would require at least a new intermediate CA.


Kurt

[Jakob Bohm]

I have encountered at least one in-the-wild certificate where one of
the pure ASCII name components was tagged as a T61STRING. This caused
problems when a broken crypto library silently converted this to
UTF8String, resulting in a DN with a different DER encoding than the DN
in the certificate it was supposed to match.

I have no idea what you are trying to say about "requiring at least a
new intermediate CA".

[Kurt Roeckx]

On 2016-03-11 15:33, Jakob Bohm wrote:
> On 11/03/2016 09:55, Kurt Roeckx wrote:
>> On 2016-03-11 01:14, Jakob Bohm wrote:
>>>> - Non-PrintableString/UTF8String in DNs. Workaround to be removed in
>>>> Bug #[TBD].
>>>
>>> Does this also apply to "pure ASCII" fields such as country ("C=US")
>>> etc.? Some of those were historically constrained to one of the
>>> lesser ASN.1 string types.
>>
>> I think C is only a PrintableString, while at least some Turkish CA has
>> that as an UTF8String. It would require at least a new intermediate CA.
>>
>>
>
> I have encountered at least one in-the-wild certificate where one of
> the pure ASCII name components was tagged as a T61STRING. This caused
> problems when a broken crypto library silently converted this to
> UTF8String, resulting in a DN with a different DER encoding than the DN
> in the certificate it was supposed to match.
>
> I have no idea what you are trying to say about "requiring at least a
> new intermediate CA".

If you start to reject based on this, and it's the issuer name itself
has that problem, all the certificate it signs will be rejected.


Kurt

[Kathleen Wilson]

On 3/10/16 9:25 PM, Eric Mill wrote:
> Would this be a good opportunity to ask CAs to do an audit of any
> undisclosed cross-signatures they may have to other unconstrained roots?
>
> For example, there were two recently discovered cross-signatures to the
> Federal Bridge by commercial CAs, Identrust and Symantec. Once it was
> identified that Identrust had not disclosed this cross-signature, Identrust
> revoked it:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c26
>
> While services like censys.io and crt.sh are doing wonders for finding
> things like this, it would also be beneficial to have CAs use their own
> vantage point over their cross-signatures to identify other possible gaps
> between what Mozilla understands their root store to trust and what it
> could potentially be made to trust.

I agree, but not sure what else to say in the communication.

~~

ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the
requirement that CAs must provide public-facing documentation about
certificate verification requirements and annual public attestation of
conformance to the stated certificate verification requirements for all
certificates that are capable of being used to issue new certificates,
and which directly or transitively chain to their certificate(s)
included in Mozilla's CA Certificate Program that are not technically
constrained as described in section 9 of Mozilla's CA Certificate
Inclusion Policy.

Respond with the date by which you plan to complete entry into Mozilla's
CA Community in Salesforce of the PEM data, CP/CPS, and audit statements
for all certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to your
certificate(s) included in Mozilla’s CA Certificate Program that are not
technically constrained as described in section 9 of Mozilla's CA
Certificate Inclusion Policy. This includes every intermediate
certificate (chaining up to your root certificates in Mozilla's program
with the Websites trust bit enabled) that is not Technically Constrained
via Extended Key Usage and Name Constraint settings.

The date that you enter must be on or before [DATE TBD]. (Required)

~~

If it is not clear enough that cross-certs are included in this, then
what additional wording do you recommend?

Thanks,
Kathleen

[kwi...@mozilla.com]

On Thursday, March 10, 2016 at 4:14:45 PM UTC-8, Jakob Bohm wrote:
> General: Throughout this document you use phrases such as "all
> certificates that directly or transitively chain to your root
> certificate(s) included in Mozilla's CA Certificate Program",
> shouldn't those phrases exclude technically constrained subCAs,
> such as subCAs used exclusively for codesigning (which has a near
> indefinite need for SHA-1 certs due to Microsoft actions).
>

I think this only applies to the SHA1 action item...

ACTION 1 -- SHA1
I think we want this action item to apply to all S/MIME and TLS/SSL certificates chaining up to included roots, regardless of whether the intermediate is constrained or not. Correct?

ACTION 2 -- enter intermediate certs into CA Community in Salesforce
Says ... that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy.

ACTION 3 -- OneCRL
Says ...and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy.

ACTION 4 -- removing workarounds from mozilla::pkix
It won't matter if the intermediates are technically constrained, the code will still reject certs that are issued after the date with those problems.

ACTION 5 -- removing retired roots
Constraints not applicable

ACTION 6 -- test certs
I guess it depends if we say anything further about test certificates other than all certs must comply with Mozilla's CA Cert Policy. Should we say anything else here?


Thanks,
Kathleen

[Charles Reiss]

On 03/10/16 23:43, kwi...@mozilla.com wrote:
[snip]

> Regards,
>
> Kathleen Wilson Mozilla CA Program Manager
>
> ACTION #1a: As previously communicated, CAs should no longer be
> issuing SHA-1 certificates chaining up to root certificates included
> in Mozilla's CA Certificate Program. Check your systems and those of
> your subordinate CAs to ensure that SHA-1 certificates chaining up to
> your included root certificates are no longer being issued. Please
> enter the last date that a SHA-1 certificate was issued that chained
> up to your root certificate(s) included in Mozilla's program.
> (Required)

Mozilla should make clear how this question should be answered with
respect to issuance of:
a) SHA-1 subCAs which are constrained by EKU to not issue TLS server or
email certs (e.g. for code signing);
b) SHA-1 end-entity certificates which are constrained by EKU to not be
for TLS servers or email certs but whose issuing subCA is not so
constrained;
c) SHA-1 end-entity certificates which are not constrained by EKU but
lack a common name or SAN which can be used a server name or email
address; and
d) SHA-1 end-entity certificates whose parent CA is constrained by EKU
to not be for TLS server or email certs;

The question as written would seem to me to apply to all of these (since
"SHA-1 certificates chaining up to your included root certificates" is
not qualified), but it seems, from inclusion request discussion, that
CAs tend to think that "out of scope" certificates need not be mentioned.

[snip]

> ACTION #6: All certificates that directly or transitively chain to
> your root certificate(s) included in Mozilla's CA Certificate Program
> must comply with Mozilla's CA Certificate Policy. This includes test
> certificates.
>
> Review your policies, procedures, and auditing about issuance of test
> certificates, what domain names may be used in test certificates, and
> the domain verification procedures that must be followed for test
> certificates.
>
> [TBD] What else should we say here? -- What sort of responses to we
> want from CAs? -- Rules about testing and test certs (per Symantec
> incident) -- What sorts of things do we want to make sure CAs do and
> don't do regarding testing? (Required)

Maybe a reminder that test certificates Mozilla expects test
certificates to follow the domain validation procedures in the CA's
CP/CPS (that Mozilla presumably reviewed) and not just be issued in
compliance with the BRs per se?

[Eric Mill]

On Mon, Mar 14, 2016 at 4:08 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> On 3/10/16 9:25 PM, Eric Mill wrote:
>

>> Would this be a good opportunity to ask CAs to do an audit of any
>> undisclosed cross-signatures they may have to other unconstrained roots?
>>
>> For example, there were two recently discovered cross-signatures to the
>> Federal Bridge by commercial CAs, Identrust and Symantec. Once it was
>> identified that Identrust had not disclosed this cross-signature,
>> Identrust
>> revoked it:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c26
>>
>> While services like censys.io and crt.sh are doing wonders for finding
>> things like this, it would also be beneficial to have CAs use their own
>> vantage point over their cross-signatures to identify other possible gaps
>> between what Mozilla understands their root store to trust and what it
>> could potentially be made to trust.
>>
>
>

> I agree, but not sure what else to say in the communication.
>
> ~~

> ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the
> requirement that CAs must provide public-facing documentation about
> certificate verification requirements and annual public attestation of
> conformance to the stated certificate verification requirements for all
> certificates that are capable of being used to issue new certificates, and
> which directly or transitively chain to their certificate(s) included in
> Mozilla's CA Certificate Program that are not technically constrained as
> described in section 9 of Mozilla's CA Certificate Inclusion Policy.
>
> Respond with the date by which you plan to complete entry into Mozilla's
> CA Community in Salesforce of the PEM data, CP/CPS, and audit statements
> for all certificates that are capable of being used to issue new
> certificates, and which directly or transitively chain to your
> certificate(s) included in Mozilla’s CA Certificate Program that are not
> technically constrained as described in section 9 of Mozilla's CA
> Certificate Inclusion Policy. This includes every intermediate certificate
> (chaining up to your root certificates in Mozilla's program with the
> Websites trust bit enabled) that is not Technically Constrained via
> Extended Key Usage and Name Constraint settings.
>
> The date that you enter must be on or before [DATE TBD]. (Required)

> ~~
>
> If it is not clear enough that cross-certs are included in this, then what
> additional wording do you recommend?

I'll admit that I had overlooked this -- this completely describes what I
was asking about.

However, just for extra emphasis, it might be useful to work the phrase
"cross-signature" or similar into the paragraph, to make sure that CAs are
reminded to consider these when evaluating your action request.

One way of doing this might be adding to the end of the first paragraph:
"This can include cross-signatures that create a chain to issuing
certificates owned by third parties, whether or not those issuing
certificates are already part of the Mozilla CA Certificate Program."

In any case, apologies for not noticing this section before making my
request.

-- Eric

[kwi...@mozilla.com]

On Monday, March 14, 2016 at 10:11:20 PM UTC-7, Eric Mill wrote:
>
> However, just for extra emphasis, it might be useful to work the phrase
> "cross-signature" or similar into the paragraph, to make sure that CAs are
> reminded to consider these when evaluating your action request.
>
> One way of doing this might be adding to the end of the first paragraph:
> "This can include cross-signatures that create a chain to issuing
> certificates owned by third parties, whether or not those issuing
> certificates are already part of the Mozilla CA Certificate Program."
>

I added a sentence to the end of the first paragraph, as suggested:
~~
ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the requirement that CAs must provide public-facing documentation about certificate verification requirements and annual public attestation of conformance to the stated certificate verification requirements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. This includes cross-signed certificates that create a chain to issuing certificates owned by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program.

Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the PEM data, CP/CPS, and audit statements for all certificates that are capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program that are not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. This includes every intermediate certificate (chaining up to your root certificates in Mozilla's program with the Websites trust bit enabled) that is not Technically Constrained via Extended Key Usage and Name Constraint settings.

The date that you enter must be on or before [DATE TBD]. (Required)
~~

Thanks,
Kathleen

[kwi...@mozilla.com]

Does the following text clear it up?

ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL and S/MIME certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL and S/MIME certificates chaining up to your included root certificates are no longer being issued. Please enter the last date that a SHA-1 based TLS/SSL certificate was issued that chained up to your root certificates included in Mozilla's program. (Required)

> [snip]
> > ACTION #6: All certificates that directly or transitively chain to
> > your root certificate(s) included in Mozilla's CA Certificate Program
> > must comply with Mozilla's CA Certificate Policy. This includes test
> > certificates.
> >
> > Review your policies, procedures, and auditing about issuance of test
> > certificates, what domain names may be used in test certificates, and
> > the domain verification procedures that must be followed for test
> > certificates.
> >
> > [TBD] What else should we say here? -- What sort of responses to we
> > want from CAs? -- Rules about testing and test certs (per Symantec
> > incident) -- What sorts of things do we want to make sure CAs do and
> > don't do regarding testing? (Required)
>
> Maybe a reminder that test certificates Mozilla expects test
> certificates to follow the domain validation procedures in the CA's
> CP/CPS (that Mozilla presumably reviewed) and not just be issued in
> compliance with the BRs per se?

How about the following?

ACTION #6: All certificates that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates.

Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates. (Required)

[checkbox] I confirm that I understand that all TLS/SSL certificates chaining up root certificates included in Mozilla's CA Certificate Program, without exception, must conform to Mozilla's CA Certificate Policy and the domain validation procedures documented in our CP/CPS.


Thanks,
Kathleen

[kwi...@mozilla.com]

On 3/15/16 5:16 AM, Gervase Markham wrote:
>> This survey requests a set of actions on your behalf, as a

>> participant in Mozilla's CA Certificate Program by [DATE TBD].
>
> In general, I think that dates should be set the same distance in the
> future as previous CA communications. It seems that most CAs have not
> had a problem complying with the previous timelines we have set. In the
> past, we've given them 3 weeks to respond - that seems plenty.
>
> Some of the items have individual response deadlines, and there is a
> master response deadline here at the top. If we have both, we need to be
> clear on how they relate.
>

Updated. I've used April 22, 2016, as the date by which CAs must respond to the communication, assuming I get it sent by the end of March.

>
>> To respond to this survey, please login to the CA Community in
>> Salesforce, click on the 'CA Communications (Page)' tab, and select
>> the 'March 2016 CA Communication' survey. Please enter your initial
>> response by [DATE TBD]. After that, you may update your responses
>> until the survey Expiration Date of [TBD], by following these same
>> steps.
>

> I don't think it's necessary to have different initial response and
> final response dates. We should just have a response date, noting that
> CAs can update their answers.
>

OK. Expiration date info removed.

>> ACTION #1a: As previously communicated, CAs should no longer be
>> issuing SHA-1 certificates chaining up to root certificates included
>> in Mozilla's CA Certificate Program. Check your systems and those of
>> your subordinate CAs to ensure that SHA-1 certificates chaining up to
>> your included root certificates are no longer being issued. Please
>> enter the last date that a SHA-1 certificate was issued that chained
>> up to your root certificate(s) included in Mozilla's program.
>> (Required)
>

> This is one overall date, not one date per root, right?

Correct, one overall date.

It now says:
"... Please enter the last date that a SHA-1 based TLS/SSL certificate was issued that chained up to your root certificates included in Mozilla's program."

OK?

>
>> ACTION #1b: Enter the date when all of the SHA-1 certificates that
>> chain up to your root certificate(s) included in Mozilla's CA
>> Certificate Program will either expire or be revoked. As previously
>> communicated we plan to show the "Untrusted Connection" error
>> whenever a SHA-1 certificate is encountered in Firefox after January
>> 1, 2017. (Required)
>

> Again, this is one overall date, not one per root?

Correct.

It now says:
"ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked. As previously communicated we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017. (Required)"

OK?

>
>> ACTION #1c: Enter the date by which safeguards will be put into place
>> that will prevent the future issuance of SHA-1 certificates that
>> chain up to your root certificate(s) included in Mozilla's CA
>> Certificate Program. If you have already completed this, then please
>> enter the approximate date when those safeguards were completed.
>> (Required)
>

> Are we requiring such safeguards? If not, then there needs to be a "not
> implemented" option. If so, then we need to be clearer about explaining
> where we promulgated that requirement.

I am not aware of requirements about putting safeguards in place.

How about if I delete action 1c, and add the following sentence to action 1b?
"We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program."

>
>> ACTION #5: Review the root certificates that you currently have
>> included in Mozilla's CA Certificate Program, and let us know which
>> of your root certificates may be removed, and when.
>

> I would say "whether any of them can now be removed or could be removed
> in the next year and, if so, when."
>

Updated. Now it says:
"ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Issuer Field and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed. (Required)"

>> Review your policies, procedures, and auditing about issuance of test
>> certificates, what domain names may be used in test certificates, and
>> the domain verification procedures that must be followed for test
>> certificates.
>

> This is merely a requirement to review, not a question to answer. Is
> that intentional?

>
>> [TBD] What else should we say here? -- What sort of responses to we
>> want from CAs? -- Rules about testing and test certs (per Symantec
>> incident) -- What sorts of things do we want to make sure CAs do and
>> don't do regarding testing? (Required)
>

> We could simply get an "I confirm that I understand that all
> certificates issued, without exception, must conform to the Mozilla
> policy requirements" checkbox.

Updated as follows:

"ACTION #6: All certificates that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates.

Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates. (Required)

[checkbox] ACTION #6: All certificates that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy. This includes test certificates.

Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates. (Required)

[checkbox] I confirm that I understand that issuance of TLS/SSL certificates chaining up root certificates included in Mozilla's CA Certificate Program, without exception, must conform to Mozilla's CA Certificate Policy and the domain validation procedures documented in our CP/CPS."

OK?

Thanks,
Kathleen

[Charles Reiss]

For reasons discussed in thread on BR scope here (that restrictions from
certificate contents won't be effective against a chosen-prefix
collision attack), I was hoping that Mozilla would ask whether CAs would
continue issuing any SHA-1 certificates, regardless of suitability for
TLS or S/MIME (except those that chain through technically constrained
subCAs issued before 2016). But perhaps that needs to be done in context
of more expansive improvements to Mozilla's policies.

>> [snip]
>>> ACTION #6: All certificates that directly or transitively chain
>>> to your root certificate(s) included in Mozilla's CA Certificate
>>> Program must comply with Mozilla's CA Certificate Policy. This
>>> includes test certificates.
>>>
>>> Review your policies, procedures, and auditing about issuance of
>>> test certificates, what domain names may be used in test
>>> certificates, and the domain verification procedures that must be
>>> followed for test certificates.
>>>
>>> [TBD] What else should we say here? -- What sort of responses to
>>> we want from CAs? -- Rules about testing and test certs (per
>>> Symantec incident) -- What sorts of things do we want to make
>>> sure CAs do and don't do regarding testing? (Required)
>>
>> Maybe a reminder that test certificates Mozilla expects test
>> certificates to follow the domain validation procedures in the
>> CA's CP/CPS (that Mozilla presumably reviewed) and not just be
>> issued in compliance with the BRs per se?
>
>
> How about the following?

This seems to address that.

My suspicion is that CAs generally think their test certificates comply
with Mozilla's policy in terms of certificate contents, so maybe that is
not the right thing to emphasize? My guess is that the real problems are
ad-hoc and/or unpublished policies for how compliance is to be achieved.
I think this is clearly prohibited by Mozilla's policies (which, e.g.,
require CAs notify Mozilla when "its policies and business practices
change in regards to verification procedures for issuing certificates").

[Jakob Bohm]

I would suggest that in order to make themselves compliant, CAs should
be allowed to internally generate and issue a very limited number of
new technically constrained SHA-1 subCAs, where extreme precautions are
taken to ensure the internal data to be signed does not facilitate
SHA-1 collisions. The major CAs probably did that before the 1/1/2016
deadline, but some of the smaller CAs may have not gotten that done yet.

[Gervase Markham]

All this seems fine :-)

Gerv

[kwi...@mozilla.com]

On Wednesday, March 16, 2016 at 6:03:26 AM UTC-7, Jakob Bohm wrote:
> On 16/03/2016 00:27, Charles Reiss wrote:

> > On 03/15/16 22:43, kwilson wrote:
> >> ACTION #1a: As previously communicated, CAs should no longer be
> >> issuing SHA-1 certificates chaining up to root certificates included

> >> in Mozilla's CA Certificate Program. This includes TLS/SSL and S/MIME
> >> certificates, as well as any intermediate certificates that they
> >> chain up to. Check your systems and those of your subordinate CAs to
> >> ensure that SHA-1 based TLS/SSL and S/MIME certificates chaining up
> >> to your included root certificates are no longer being issued. Please
> >> enter the last date that a SHA-1 based TLS/SSL certificate was issued
> >> that chained up to your root certificates included in Mozilla's
> >> program. (Required)
> >
> > For reasons discussed in thread on BR scope here (that restrictions from
> > certificate contents won't be effective against a chosen-prefix
> > collision attack), I was hoping that Mozilla would ask whether CAs would
> > continue issuing any SHA-1 certificates, regardless of suitability for
> > TLS or S/MIME (except those that chain through technically constrained
> > subCAs issued before 2016). But perhaps that needs to be done in context
> > of more expansive improvements to Mozilla's policies.
> >

Should we add a question to the survey about each CA's plans for issuance of SHA-1 based certificates other than TLS/SSL and S/MIME certificates that chain up to their included root certs?

>
> I would suggest that in order to make themselves compliant, CAs should
> be allowed to internally generate and issue a very limited number of
> new technically constrained SHA-1 subCAs, where extreme precautions are
> taken to ensure the internal data to be signed does not facilitate
> SHA-1 collisions. The major CAs probably did that before the 1/1/2016
> deadline, but some of the smaller CAs may have not gotten that done yet.
>

Are you saying that CAs should be able to issue SHA-1 intermediate certificates that are capable of issuing TLS/SSL certificates but are technically constrained via name constraints to certain domains?

Thanks,
Kathleen

[Charles Reiss]

If Mozilla intends to use the survey to inform its decision about
whether to distrust all SHA-1 certificates earlier than the current Jan
2017 date, yes.

>>
>> I would suggest that in order to make themselves compliant, CAs
>> should be allowed to internally generate and issue a very limited
>> number of new technically constrained SHA-1 subCAs, where extreme
>> precautions are taken to ensure the internal data to be signed does
>> not facilitate SHA-1 collisions. The major CAs probably did that
>> before the 1/1/2016 deadline, but some of the smaller CAs may have
>> not gotten that done yet.
>>
>
>
> Are you saying that CAs should be able to issue SHA-1 intermediate
> certificates that are capable of issuing TLS/SSL certificates but are
> technically constrained via name constraints to certain domains?

I assume the idea is that the intermediates are technically constrained
from signing TLS or S/MIME certificates at all; for example, with an
extendedKeyUsage extension containing only code signing.

>
> Thanks, Kathleen
>

[kwi...@mozilla.com]

The following 'ACTION #1c' has been added to the communication, which is here:
https://wiki.mozilla.org/CA:Communications#March_2016
and click on "Link to DRAFT of March 2016 CA Communication".

~~
ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1.

To what extent are SHA-1 based signatures still used in your infrastructure, including your root certificates that you currently have included in Mozilla's CA Certificate Program, as well as any CAs subordinate to them?

Please check all the boxes below that apply. (Required)

(a) There is no use of SHA-1 based signatures in our infrastructure.
(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
(c) We use SHA-1 to sign OCSP responses, directly under a CA certificate.
(d) We use SHA-1 to sign certificates.
(e) We use SHA-1 signing in some other way.

ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation.

If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks.

If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks?

If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.

[kwi...@mozilla.com]

On Tuesday, March 22, 2016 at 9:33:19 AM UTC-7, kwi...@mozilla.com wrote:
> The following 'ACTION #1c' has been added to the communication, which is here:
> https://wiki.mozilla.org/CA:Communications#March_2016
> and click on "Link to DRAFT of March 2016 CA Communication".
>

Also, I have filled in proposed dates, assuming I send the communication next week.

I used two dates...

April 22,2016 -- the date by which CAs must enter their initial response to this communication into the CA Community in Salesforce.

June 30, 2016 -- the date by which CAs must take the requested actions: enter intermediate cert data into the CA Community in Salesforce, and stop issuing certs with the problems listed in ACTION #4.

I would especially like to hear from CAs in regards to if these dates are reasonable.

Thanks,
Kathleen

[Charles Reiss]

On 03/22/16 16:33, kwi...@mozilla.com wrote:
> The following 'ACTION #1c' has been added to the communication, which
> is here: https://wiki.mozilla.org/CA:Communications#March_2016 and
> click on "Link to DRAFT of March 2016 CA Communication".

With the current wordings of #1a and #1b, if
- a CA has both the email and websites trust bits; and
- their last SHA-1 S/MIME certificate {was issued,expires} later than
their last SHA-1 TLS server certificate,
then they should give the TLS date. Is this intentional?

[Kathleen Wilson]

Yes, that is intentional. For #1a and #1b I would like to know the TLS
date, because it might influence our decisions in regards to when we
make some changes in Firefox regarding SHA-1.

Kathleen

[Kathleen Wilson]

On 3/23/16 10:26 AM, Jeremy Rowley wrote:
> What about code signing and s/MIME certs? Code signing is still used by MS
> for legacy software until Jan 2017.

>
> On Tuesday, March 22, 2016 at 9:33:19 AM UTC-7, kwi...@mozilla.com wrote:

>> The following 'ACTION #1c' has been added to the communication, which is
> here:
>> https://wiki.mozilla.org/CA:Communications#March_2016
>> and click on "Link to DRAFT of March 2016 CA Communication".
>>

Jeremy, I'm not sure I understand your question. Is it in regards to
ACTION #1c?

Kathleen

[Kathleen Wilson]

On 3/23/16 11:04 AM, Jeremy Rowley wrote:
> Yes. 1c encompasses all certs, which includes code signing (not supported by
> Mozilla) and client (somewhat supported by Mozilla). If we have to change
> by June 30, 2016, this is trumping the Microsoft date, despite Mozilla
> dropping support for code signing certificates last year.
>


There is no date specified in ACTION #1c.

The June 30 date is in ACTION #2 (intermediate cert data in CA Community
in Salesforce), #3 (OneCRL data in CA Community in Salesforce), and #4
(removing workarounds to BR non-comformance).

Thanks,
Kathleen

[Richard Barnes]

I think that yes, the response to #1c should include code signing
certificates. As the description notes, anything a CA signs presents a
risk.

I'm not sure what you're saying about June 30, 2016? I don't think this
question is related to actual enforcement, just trying to gauge the degree
of residual risk that is out there even after the prohibition on SHA-1 web
certs.

On Wed, Mar 23, 2016 at 2:04 PM, Jeremy Rowley <jeremy...@digicert.com>

wrote:

> Yes. 1c encompasses all certs, which includes code signing (not supported
> by
> Mozilla) and client (somewhat supported by Mozilla). If we have to change
> by June 30, 2016, this is trumping the Microsoft date, despite Mozilla
> dropping support for code signing certificates last year.
>
>

> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley
> =digice...@lists.mozilla
> .org] On Behalf Of Kathleen Wilson
> Sent: Wednesday, March 23, 2016 11:46 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Drafting Q1 2016 CA Communication
>
> On 3/23/16 10:26 AM, Jeremy Rowley wrote:
> > What about code signing and s/MIME certs? Code signing is still used
> > by MS for legacy software until Jan 2017.
> >
> > On Tuesday, March 22, 2016 at 9:33:19 AM UTC-7, kwi...@mozilla.com
> wrote:

> >> The following 'ACTION #1c' has been added to the communication, which
> >> is
> > here:
> >> https://wiki.mozilla.org/CA:Communications#March_2016
> >> and click on "Link to DRAFT of March 2016 CA Communication".
> >>
>

> Jeremy, I'm not sure I understand your question. Is it in regards to ACTION
> #1c?
>
> Kathleen
>
>

[Jakob Bohm]

On 23/03/2016 18:26, Jeremy Rowley wrote:
> What about code signing and s/MIME certs? Code signing is still used by MS
> for legacy software until Jan 2017.
>

Wrong date, Wrong data.

Until Jan 2017, the Microsoft systems that accept SHA-256 code signing
and associated (logically unrelated, but practically related) code
signing features, will accept new time stamp authority signatures made
using SHA-1, however those systems already refuse new code signing
signatures made using SHA-1 after Jan 2016 (but see 2 paragraphs
below)

For an *unlimited* time, the Microsoft Operating Systems for which they
have refused to provide the updated code signing features will
continue to *require* that the first in an ordered set of code signing
signatures on a file is created exclusively using SHA-1 or MD5. This
requirement is the reason the major CAs have set up various subCAs that
issue code signing X.509 certificates AND time stamp authority
signatures acceptable to this old verification code.

For an *unlimited* time, the Microsoft Operating Systems with the new
features will allow files to carry multiple signatures in an ordered
set (similar but not identical to how the jar file standard used by
Mozilla extensions allows multiple signatures via multiple signature
file names). In all but one (annoying) case these systems will accept
a file as long as at least one signature is good enough for the then
current criteria.

For an *unlimited* time, an unspecified set of 3rd party systems will
also insist on SHA-1 certificates for various uses where broken SHA-1
is still better than nothing. In most cases this is limited only by
the physical hardware lifetime (consider the recent request from a
payment provider that had failed to obtain a 2015 certificate for
talking to a minority of hardware scheduled for later replacement, then
consider less security critical uses where the associated hardware
would not be updated just to allow the central system to switch to a
better algorithm).

> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
> .org] On Behalf Of kwi...@mozilla.com
> Sent: Tuesday, March 22, 2016 10:49 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Drafting Q1 2016 CA Communication
>

> On Tuesday, March 22, 2016 at 9:33:19 AM UTC-7, kwi...@mozilla.com wrote:

>> The following 'ACTION #1c' has been added to the communication, which is
> here:
>> https://wiki.mozilla.org/CA:Communications#March_2016
>> and click on "Link to DRAFT of March 2016 CA Communication".
>>
>

> Also, I have filled in proposed dates, assuming I send the communication
> next week.
>
> I used two dates...
>
> April 22,2016 -- the date by which CAs must enter their initial response to
> this communication into the CA Community in Salesforce.
>
> June 30, 2016 -- the date by which CAs must take the requested actions:
> enter intermediate cert data into the CA Community in Salesforce, and stop
> issuing certs with the problems listed in ACTION #4.
>
> I would especially like to hear from CAs in regards to if these dates are
> reasonable.
>
> Thanks,

> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Kathleen Wilson]

Last call for review of the draft of the March 2016 CA Communication...

I am planning to send it tomorrow (Tuesday) or Wednesday.

> To view the draft of the March 2016 CA Communication as
> it will appear for each CA in Salesforce, please browse to

> https://wiki.mozilla.org/CA:Communications#March_2016
> and click on "Link to DRAFT of March 2016 CA Communication"
>

Thanks,
Kathleen

[David Keeler]

On 03/10/2016 04:14 PM, Jakob Bohm wrote:
...

>> - Non-PrintableString/UTF8String in DNs. Workaround to be removed in
>> Bug #[TBD].
>
> Does this also apply to "pure ASCII" fields such as country ("C=US")
> etc.? Some of those were historically constrained to one of the
> lesser ASN.1 string types.

Yes. As far as I can tell, Country must be a PrintableString consisting
of a two-letter country code from ISO 3166-1 (or "XX" as permitted by
the BRs). Of course, RFC 5280 does have some wiggle-room regarding
interoperability with preexisting certificates. Going forward, however,
all DNs should use the allowed encodings.