[cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - July 14, 2022

Thu Jul 14 16:19:39 UTC 2022

These are the Draft Minutes of the Teleconference described in the 
subject of this message as prepared by Dimitris Zacharopoulos (HARICA).*
*

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

    Antitrust statement

The Antitrust Statement was read.

    Approval of minutes

Two sets of meetings were approved:

  * June 16, 2022
  * June 30, 2022

    Agenda

 1. Review list of discussions at the F2F
    (https://lists.cabforum.org/pipermail/validation/2022-July/001778.html)
 2. Call for volunteers to draft language for the various items discussed

    Minutes

Corey gave an update about the relocation of the profiles work that 
moved to a cabf GitHub branch 
https://github.com/cabforum/servercert/pull/373

      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

No discussion.

        Allow for previous version of the profile until new effective date

No discussion.

        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
      3.2.2.4 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 
GRID certificates.

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 asked Microsoft Engineers and their response was that 
they decide on the path before reading the Root Certificate.

Dustin said he would ask around but might not get a definitive answer.

Wendy mentioned that this information came from the Microsoft CAPI team.

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 
and confirm.

Clint: AKI matching/chain-building, here's an (older) article that 
describes how AKI is used in some older Windows versions: 
https://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx#Path_Construction_and_Validation

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 
protocols.

    Next call

scheduled for July 28th

    Adjourned
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220714/d1fe1c7b/attachment-0001.html>