On 11/03/2016 00:43, kwil...@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
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].
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
