[cabf_validation] 2nd draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - July 14, 2022
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Jul 15 06:52:10 UTC 2022
This is the 2nd draft of the Minutes of the Teleconference described in
the subject of this message as prepared by Dimitris Zacharopoulos
(HARICA) and updated by Wendy Brown (FPKI).*
Please review the minutes and propose edits if necessary. These minutes
will be considered for approval at the next meeting. The recording of
the meeting will be deleted once the minutes are approved.
Attendees(in alphabetical order)
1. Aaron Poulsen - Amazon Trust Services
2. Andrea Holland - SecureTrust
3. Aneta Wojtczak - Microsoft
4. Ben Wilson - Mozilla
5. Chris Clements - Google
6. Clint Wilson - Apple
7. Corey Bonnell - Digicert
8. Dimitris Zacharopoulos - HARICA
9. Dustin Hollenback - Microsoft
10. Janet Hines - SecureTrust
11. Joanna Fox - TrustCor Systems
12. Joe Ramm - OATI
13. Michael Slaughter - Amazon Trust Services
14. Michelle Coon - OATI
15. Trevoli Ponds-White - Amazon Trust Services
16. Wayne Thayer - Fastly
17. Tobias Josefowitz - Opera
18. Tyler Myers - Godaddy
19. Wendy Brown - FPKI
The Antitrust Statement was read.
Approval of minutes
Two sets of meetings were approved:
* June 16, 2022
* June 30, 2022
1. Review list of discussions at the F2F
2. Call for volunteers to draft language for the various items discussed
Corey gave an update about the relocation of the profiles work that
moved to a cabf GitHub branch
Review of list of discussions at the F2F
Clint made a general comment that he wants to avoid a possible
misunderstanding that just because some requirements are more explicitly
stated in the new version doesn't mean that the requirements were not
existent in the current version. It should not be interpreted that if it
is now explicitly stated it's not already a requirement in existing
language. Some of those requirements are infered by normative RFCs and
other parts of the BRs.
Top-level effective date for new profile
Allow for previous version of the profile until new effective date
Defer prohibition on keyAgreement in ECDSA certs and
dataEncipherment until v2
For the prohibition of those two KeyUsages, Clint believes some
restrictions are already in place today because it should be considered
not just based on the KU and algorithm but also in combination of the
id-kp-serverAuth EKU. However, he's ok to defer to v2 but CAs must not
conflict with existing RFCs.
Add carve-out for multiple DC attributes (GRID)
Clint wants to address this and respond to the GRID community.
Corey mentioned that we should not include the DC in the SAN values and
restore ballot 110 language. Clint agreed.
Update subject attribute validation requirements to not require
184.108.40.206 validation for those fields whose validation steps are
documented in the BRs
Corey reminded that the issue was if a Domain Name is included in the
Certificate, what elements need to be validated. Clint understands that
addressing this issue may cause more issues than it resolves so he wants
to be careful.
Call for volunteers to draft language for the various items discussed
Dimitris offered to assist in the language for the DC attributes for the
Corey will reach out to Tim Hollebeek to try to take a stab on the first
two items. Clint can assist in those items too.
Aneta volunteered to draft language for the two Key Usages issue.
Corey will take a stab at the last one.
Wendy Brown asked about the request to make the AKI a SHOULD in the Root
Certificate. She had asked Microsoft employees who told her they had
checked with the CAPI team and were told that the path decision would be
based on other factors before CAPI would check whether the AKI was
present in a root certificate and matched the SKI in that certificate.
The exact response she received was: “If a cross-certificate is
preferred, it would be for other reasons and not the absence of the AKI
in the root. If the AKI isn’t present, then, the encoded Issuer and
Subject names must be identical in a root. I would expect other fields
in the cert, such as NotBefore/NotAfter to be used before AKI would even
Dustin said he would ask around but might not get a definitive answer.
Aneta mentioned that AKI/SKI is first checked for path building. If it
is not set, then the subject/issuerDN values are used. She will check
Clint: AKI matching/chain-building, here's an (older) article that
describes how AKI is used in some older Windows versions:
Corey recalled Wendy asking a question about the policyConstraints
extension. Upcoming prohibition in OCSP responders might cause a problem
because the FPKI requires all Certificates to include a
certificatePolicies extension, including OCSP responder Certificates.
Dimitris asked whether the inclusion of the certificatePolicies
extension in an OCSP Responder Certificate is currently prohibited.
Wendy mentioned that it's not clearly restricted. Corey confirms that
there are no restrictions for the OCSP responder certificate profiles
except for the id-pkix-ocsp-nocheck (RFC6960) extension.
Corey said we can add future effective date for such a change. Clint
mentioned that this change should have its own effective date outside of
the top-level one.
Wendy asked about the Subject Information Access extension in Root
Certificates. Corey mentioned that it is a SHOULD NOT as captured by the
"any other extensions" clause in the BRs.
Any Other Business
Corey said there are other topics in the backlog. He was thinking that
we could split the first 30' to discuss about the profiles work and the
rest on other topics from the backlog.
He mentioned some topics:
* EV Guidelines pointing to the BRs for some common areas
* Delegation to the CA for Domain Validation
* Securing Domain Validations (RPKI, DNSSEC)
Clint mentioned his interest to discuss some OCSP SLA improvements.
Corey mentioned that this is work in progress at the NetSec WG and asked
Clint to ask on the servercert list.
Wayne said that if a person wants to drive discussion on a certain
topic, we should prioritize that topic. Clint agreed.
Dimitris mentioned that it might be a good idea to review a list of
currently open issues on the next call, remove topics that are no longer
interesting, add others that are of current interest, and prioritize.
Wayne and Corey agreed to proceed with this.
Wayne wanted to add an issue regarding methods 6 and 19 whether a CA
must follow HSTS directives. If they use HTTPS, should they properly
validate the certificate chain? What root store should they use? It's
not very clear in the current BRs but it might make sense to clarify in
a future revision of the BRs.
Corey thinks this is a good topic to discuss. By extension, some similar
questions apply to the Domain Validation methods related to the DNS
scheduled for July 28th
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation