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

Thu Jul 14 17:53:20 UTC 2022

Dimitris
I would like to clarify what I said - see edits below

From: Validation <validation-bounces at cabforum.org> On Behalf Of Dimitris Zacharopoulos (HARICA) via Validation
Sent: Thursday, July 14, 2022 12:20 PM
To: validation at cabforum.org
Subject: [cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - July 14, 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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fvalidation%2F2022-July%2F001778.html&data=05%7C01%7Cwendy.brown%40protiviti.com%7C2bf708b2dc19486c0ebb08da65b4aed7%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637934123957607921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DhTyCxyE3HcE4XGCj49wrO1PPZ8lqb57CBl6gYL5ePc%3D&reserved=0>)
  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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fpull%2F373&data=05%7C01%7Cwendy.brown%40protiviti.com%7C2bf708b2dc19486c0ebb08da65b4aed7%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637934123957607921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1ABZ%2BdbvUrgMTOVhpK%2BhAKPRig6yKfnUL10oMLPPhRA%3D&reserved=0>

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. I said I had asked Microsoft employees who told me 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.  (Although I didn't have the email during  the call the exact response I had 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.

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<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsocial.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F4954.windows-xp-certificate-status-and-revocation-checking.aspx%23Path_Construction_and_Validation&data=05%7C01%7Cwendy.brown%40protiviti.com%7C2bf708b2dc19486c0ebb08da65b4aed7%7C16532572d5674d678727f12f7bb6aed3%7C0%7C0%7C637934123957764148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k%2BnmJulpr0d%2FS%2B0ejZWWJPw603%2F6qeAPXP9OoWnXPww%3D&reserved=0>

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
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20220714/94701a80/attachment-0001.html>