[cabf_validation] Draft Minutes for the Validation Subcommittee Server Certificate Working Group Teleconference - October 06, 2022
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
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>
More information about the Validation
mailing list