On 5/4/20 9:31 AM, Corey Bonnell wrote:
Thank you very much for the clarifications. If I'm understanding correctly, it
sounds like Mozilla is considering to add sub-items of item 4 on the survey as
Mozilla Root Program requirements if the associated CAB Forum ballot does not
pass. However, there is concern that many CAs may not be compliant with these
requirements, so the purpose of the survey is to gauge potential impact to CAs
so that effective dates can be set such that CAs can react appropriately as
well as to gather data to better inform Mozilla's position in the CAB Forum.
Is that a correct assessment of the purpose of question 4?
Correct.
I created the issues in Github so these items get considered for
Mozilla's policy in one form or other (direct, through BRs, or both).
Here is a breakdown of my perspective of the Browser Alignment Ballot
(https://github.com/sleevi/cabforum-docs/pull/10) specifically in
regards to Mozilla’s Root Store Policy.
Audit Reporting
- CAs should already be following all but one of the additions, because
they are already part of section 3.1.4 of Mozilla’s Root Store Policy[1]
and section 5.1 of the CCADB Policy[2].
- I filed https://github.com/mozilla/pkipolicy/issues/210 for the
requirement that would be new to Mozilla policy: “CCADB Policy: Require
audit statements to be text-searchable PDF”
(SUB ITEM 4.3 in the May 2020 CA Communication/Survey.)
OCSP
- I filed https://github.com/mozilla/pkipolicy/issues/211 to consider
updating section 6 of Mozilla’s Root Store Policy: “Require OCSP and
Reduce OCSP response max validity from 10 days to 7 days”
(SUB ITEM 4.4 in the May 2020 CA Communication/Survey.)
- Mozilla may propose in the CABF that the other three items in this
section be removed from the ballot (fresh OCSP responses at one-half of
validity interval, must contain revocationReason, must not contain a
reasonCode singleExtension).
CRLs
- Mozilla may propose in the CABF that these changes be removed from the
ballot (reasonCode requirements for intermediate cert revocations). I
don't see a reason for Mozilla to require this or enforce such a rule.
Certificate Policies
- I filed https://github.com/mozilla/pkipolicy/issues/212 to consider
updating Mozilla’s Root Store Policy if this doesn’t get added to the
BRs: “Require at least one CABF defined-policy OID in
certificatePolicies extension for TLS certs”
(SUB ITEM 4.1 in the May 2020 CA Communication/Survey.)
Authority Key ID
- CAs should already be following this item because it is already part
of RFC 5280 and section 5.2 of Mozilla’s Root Store Policy. (RFC 5280:
authorityKeyIdentifier MUST be present and MUST contain a keyIdentifier,
Mozilla Policy: “CAs MUST NOT issue certificates that have … authority
key IDs that include both the key ID and the issuer’s issuer name and
serial number”)
Extended Key Usage
- CAs should already be following this item because it is already part
of section 5.3 of Mozilla’s Root Store Policy.
Name Encoding Rules
- I filed https://github.com/mozilla/pkipolicy/issues/213 to consider
updating Mozilla’s Root Store Policy even if this does get added to the
BRs: “Require Byte-for-byte Identical Issuer and Subject Distinguished
Names”
(SUB ITEM 4.2 in the May 2020 CA Communication/Survey.)
CP/CPS
- CAs should already be following this item because it is already in
section 3.3 of Mozilla’s Root Store Policy.
Key Algorithms and Sizes
- CAs should already be following this item because it is already in
section 5 of Mozilla’s Root Store Policy.
Signature Algorithms
- These clarifications were added to section 5 of Mozilla’s Root Store
Policy in version 2.7, with an effective date of January 1, 2020.
Certificate Lifetimes
- https://github.com/mozilla/pkipolicy/issues/204
(ITEM 3 in the May 2020 CA Communication/Survey.)
Clarify Effective Dates
- This is a clarification that seems reasonable, and does not require
action.
Thanks,
Kathleen
[1]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy
[2] https://www.ccadb.org/policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
