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

Sun Oct 9 09:01:17 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. Ben Wilson - Mozilla
 3. Chris Clements - Google
 4. Clint Wilson - Apple
 5. Corey Bonnell - Digicert
 6. Dimitris Zacharopoulos - HARICA
 7. Doug Beattie (GlobalSign)
 8. Dustin Hollenback - Microsoft
 9. Inigo Barreira - Sectigo
10. Martijn Katerbarg (Sectigo)
11. Rebecca Kelley (Apple)
12. Ryan Dickson - Google
13. Trevoli Ponds-White - Amazon Trust Services
14. Tyler Myers - GoDaddy
15. Wayne Thayer - Fastly
16. Wendy Brown - FPKI

    Antitrust statement

The Antitrust Statement was read.

    Assign minute-taker

Dimitris volunteered to take minutes. Corey will restart the rotation 
plan for minute-takers. Ryan agreed.

    Approval of minutes

Last meeting (September 22nd) minutes were approved.

    Agenda

 1. Determine F2F Agenda -- we have a 2-hour time slot.
 2. 2022-10-20 meeting – should we meet?
 3. Review and approve profiles ballot PRs/other profile ballot discussion
 4. Continue analysis of the BRs for the use of the Applicant and
    Applicant Representative defined terms.

    Minutes

      Determine F2F Agenda

Stick with existing practice and spend time to continue the work of the 
profiles and other BR improvements.

No objections to stay with this plan and keep only these 2 agenda items.

      2022-10-20 meeting – should we meet?

Several people will be traveling so the suggestion is to cancel that call.

No objections to cancel the call.

      Review and approve profiles ballot PRs

Corey shared his screen and the pull request 
https://github.com/cabforum/servercert/pull/392. He explained the 
rationale to allow a few attributes to have multiple instances in the 
subjectDN based on previous discussions, especially addressing the 
potential impact to the GRID community.

Martijn mentioned that it might be phrased as "if domainComponent is 
included, then multiple instances MUST/SHALL be present". If this is 
included, the entire commonName or one of the SAN values needs to be 
included as a reversed order Domain Name, so if we have a Domain Name 
"example.com", we would need "DC=com, DC=example" in that order. Corey 
explained that there will be multiple domainComponent attributes but he 
doesn't think that the components are necessarily taken from the FQDN of 
the SAN or commonName. It's mainly used to identify the Issuer of the 
Subject. Martijn is not bothered with a MAY but thinks a SHALL is more 
accurate.

Dimitris explained that he copied the phrase "Multiple instances MAY be 
present" from the existing streetAddress exception in the existing 
profiles ballot which gets the message across even for the 
domainComponent. Martijn did not have strong feelings so the wording is 
kept as is.

The group accepted the PR so it can be merged.

Corey mentioned about defining some encoding requirements for the 
domainComponent attribute for completeness. It's pretty straightforward 
to add a row to that table and he will make this adjustment after this 
PR is merged which we can review at the F2F.

Dimitris mentioned that there was some discussion a few weeks ago about 
multiple instances of the OU field in CA Certificates. What is the 
interpretation of the existing BRs? Is OU allowed for CA Certificates? 
If it is allowed, we should mention that multiple instances of the OU 
attribute in CA Certificates are also allowed, along with streetAddress 
and domainComponent. It is clearly not allowed for end-entity 
certificates but the BRs are silent about the CA Certificates.

Doug said he will go back to check the current version of the BRs and 
clarify.

Some new requirements have been introduced

Ryan did a quick scan and discovered some recently issued intermediate 
CA Certificates that do contain OU attributes. He will do a more 
detailed search and will report back if he detects more CA Certificates 
that include OU fields and have been issued recently.

Doug checked the BRs during the call and mentioned that the current BRs 
are silent on a prohibition of OU in the CA Certificate subjectDNs but 
it's an issue of "default allow/deny". If it's "default deny", then only 
3 fields should be allowed in CA Certificates. Dimitris added that there 
are many CA Certificates related to EU Qualified Certificates that 
require the organizationIdentifier attribute to be included in the 
Issuing CA Certificate, so this interpretation would be impactful. If we 
want to explicitly deny OU attributes in CA Certificates, it would need 
to be in a future ballot, not the profiles ballot.

Since this seems to be the existing interpretation, we need an update 
allowing multiple instances of the OU attributes in CA Certificates for 
the profiles ballot. No objections to proceed with that plan.

      Continue analysis of the BRs for the use of the Applicant and
      Applicant Representative Defined Terms.

Skipping the IP address validation section, as it’s duplicative of 
section 3.2.2.4.

  * 3.2.2.6. No issues for how Applicant is used there.
  * 3.2.3: Dimitris mentioned that for IV, it makes sense for the
    Applicant to be a Natural Person and that person is validated
    against his/her ID. For OV, we need the Applicant Representative's
    ID and authority to represent the Organization. Ben said this
    section should apply only to IV Certificates because the way it's
    written even applies to an Applicant for DV Certificates. We should
    clarify at the beginning of the paragraph. Corey mentioned that the
    last sentence is more suited for 3.2.5 and suggests removing that
    sentence. Trev mentioned that instead of changing the title of the
    section, which would violate RFC 3647, we should add a first
    sentence clarifying the intent. Corey recommended adding that to the
    TODO list.
  * 3.2.5: This section is mainly used for OV Certificates. There was
    some discussion about validating practices for individuals and
    organizations. This section also needs more attention to clarify how
    the CA should validate the Applicant Representative's identity and
    authority to represent the Applicant, which in this case is a Legal
    Entity.
  * 4.1.2: Trev stated that this goes back to what Tim was saying in
    previous meetings. It's not clear who the Applicant is at that
    stage. We can define what we mean by enrollment compared to the
    certificate application processing. Wendy said we need to specify
    what we mean by a "certificate request". She believes this paragraph
    is quite confusing. Ben understands the confusion and mentioned that
    there are several models. This section is flagged as "needs to be
    revisited".

Doug asked where things stand with the Profiles ballot. Corey replied 
that we are close to the ballot with some small language improvements.

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