[cabf_validation] Minutes of the Validation Subcommittee - August 26, 2021

[Wayne Thayer]

Wayne Thayer read the antitrust statement.

Attendance: Amanda Mendieta, Andrea Holland, Aneta Wojtczak, Ben Wilson,
Bruce Morton, Corey Bonnell, Doug Beattie, Clint Wilson, Janet Hines,
Joanna Fox, Johnny Reading, Kati Davids, Michelle Coon, Mike Min, Nico
Carpenter, Natalia Kotilarsky, Rebecca Kelley, Ryan Sleevi, Shelley Brewer,
Steven Deitte, Tobias Josefowitz, Trevoli Ponds-White, Wayne Thayer

** Minute Takers: **
Wayne said that he is up this week, and Ryan Sleevi is next up.

** Agenda: **
Wayne said that the only existing agenda topic is certificate profiles.

Wayne suggested that the email to the Mozilla dev-security-policy list
titled “DNS authorization delegation through non-ADN delegated records” was
worthy of some discussion.

** Certificate Profiles **
Ryan began by reviewing the list of commits to the profiles from August
20th at https://github.com/sleevi/cabforum-docs/commits/profiles, including:

* Corey Bonnell called out the technically constrained non-TLS subCA
profile and the practice by NetLock and SecureTrust of using precertificate
signing subCAs. Another profile will be added to cover this specific EKU.
* Corey submitted a PR to reorder the street address and postal code fields
in the profiles to reflect the proper hierarchical order.
* Name constraints are a MAY for TLS subCAs.
* cRLDP MUST NOT for for OCSP responder certificates.


Work in progress changes are at
https://github.com/sleevi/cabforum-docs/pull/36#issuecomment-902878975,
including:

* Validity periods for all profiles as discussed in prior calls. Make it
clear that test certificates can be issued with an expired validity period.
* Doug Beattie asked about “any other value” - including other extensions
or values than what is listed. Arbitrary extensions will be permitted, Ryan
will clearly denote places where an arbitrary value is allowed, and
conditions for doing so.
* Corey raised a point about additional extensions that can be included,
such as signed exchange and delegated credentials. They have additional
restrictions in other fields such as key usages, so these probably make
sense as additional subscriber certificate profiles.
* Ryan will try to clarify the language around precertificates being the
presumption that a corresponding certificate exists.
* Corey mentioned the CABF identifier for EV, TLS Features, and
QCStatements extensions.  QCStatements is messier. Ryan plans to leave it
as SHOULD NOT. It’s not a goal to try to fold all the ETSI requirements
into these profiles. This will not prohibit the issuance of qualified
certificates. There is also the onion v2 certificate extension. v2 has been
sunset as of July 15 and is being removed from Tor later this year, so the
v2 rules can be cleaned up.
* SRVNames and nameConstraints language is buggy

Corey said that he will respond to Ryan’s comments soon.

Ryan said that there is some ongoing discussion around Subject Key
Identifier (SKI) and Authority Key Identifier (AKI) and how Windows 10 and
macOS verify certificates. Windows prioritizes AKI/SKI in path building,
and Windows 10 introduces logic that causes certificate validation to fail
after some number of failed signature validations. The requirement
resulting from this behavior is that unique public keys should have
distinct SKIs. macOS enforces that SKI and AKI must match, despite RFC 5280
discouraging this. So you can use multiple SKIs  for a single public key,
but you probably shouldn’t.

Another area of ongoing discussion is that the cross-certificate profile
should not be used for root certificates (subject matches issuer).

Also discussing cross certifying certificates when the root doesn’t comply
with the current requirements. The Intention is to allow this.

Finally, discussion is ongoing to allow domain name in organization fields
when appropriate, e.g. SSL.com.

Wayne asked everyone to review the profiles and comment on GitHub.

**DNS authorization delegation through non-ADN delegated records **
Wayne said that the email from Matthias (
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mMyBFRyQdw4/m/IMtOrMNOAQAJ)
was originally asking if it was permissible to follow CNAMEs under method
7, and this is know to be permitted. Ryan responded stating that it is not
permitted to delegate the CNAME to the CA. Wayne said that this might be an
area for the subcommittee to clarify.

Corey said that the conclusions are not readily apparent from a reading of
the BRs.

Ryan said that there was discussion around Subscriber/Applicant
relationship to the CA on a CAB Forum list around 2 years ago. The
Applicant has to provide the random value. Discussion was with Jeremy at
DigiCert and in part about account security controls.

Corey said the discussion was on the mozilla.dev.security.policy.list.

Ryan said that the issue goes back to the Validation Summit in Virginia.

Corey said there was some conversation in 2018 and the conclusion seemed to
indicate that consensus was the delegation would be permitted.

Doug posted the following link into the chat:
https://groups.google.com/g/mozilla.dev.security.policy/c/lT0Dd9XkPwI/m/TRFhrX52AAAJ

Doug said that it was unclear that a conclusion had been reached, but there
needed to be some security tying the random value to the Applicant.

Ryan said there was another thread with Jeremy Rowley going back to 2016.

Corey said that the thread Doug posted is the one he was referring to.

Wayne asked if this was something we should take up in the Validation
Subcommittee. Corey said yes, to ensure that if it is being done, it is
being done securely. Clint and Trev also agreed.

Wayne said that he’d add this work to the Trello board.

The call ended.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210826/b191838e/attachment.html>