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

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

    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 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 
be considered.”

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 
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/20220715/d069b40e/attachment-0001.html>