[cabf_validation] 2022-12-15 Approved Minutes

Thu Jan 12 17:17:57 UTC 2023

Thanks Doug for taking these!

Meeting of December 15, 2022

Antitrust Statement:  Corey Bonnell read the Antitrust Statement

Attendance:  

Aaron Poulsen - (Amazon), Andrea Holland - (SecureTrust), Aneta
Wojtczak-Iwanicka - (Microsoft), Ben Wilson - (Mozilla), Bruce Morton -
(Entrust), Clint Wilson - (Apple), Corey Bonnell - (DigiCert), Dimitris
Zacharopoulos - (HARICA), Doug Beattie - (GlobalSign), Dustin Hollenback -
(Microsoft), Enrico Entschew - (D-TRUST), Eva Vansteenberge - (GlobalSign),
Inigo Barreira - (Sectigo), Jamie Mackey - (US Federal PKI Management
Authority), Joanna Fox - (TrustCor Systems), Johnny Reading - (GoDaddy),
Martijn Katerbarg - (Sectigo), Michelle Coon - (OATI), Nargis Mannan -
(SecureTrust), Pekka Lahtiharju - (Telia Company), Rebecca Kelley - (Apple),
Rollin Yu - (TrustAsia Technologies, Inc.), Ryan Dickson - (Google), Thomas
Zermeno - (SSL.com), Tim Hollebeek - (DigiCert), Tobias Josefowitz - (Opera
Software AS), Trevoli Ponds-White - (Amazon), Tyler Myers - (GoDaddy), Wayne
Thayer - (Fastly)

Minutes:  Minutes of previous meetings Nov. 17th  and December 1st were both
approved.

Agenda Topics

1) Certificate Profiles

Corey sent a new PR that includes SC 56 and SC 58.  Please review and send
feedback as you have time

2) Profile ballot: Subject Key Identifiers

Cory said we're looking for feedback from the root programs on the use of
SKI in TLS certificates

Ryan wants this to remain not recommended.  We can see a reduction in TLS
handshake bandwidth by 3% which is significant.  Since SKI can be calculated
via any method, it's not a useful way to do public key lookups.  But we
could rely on SHA-256 hash of the subject public key info since that is
standard.  Not recommended is not a probation, even if some auditors take
the other view.  SKI is enabled by default in many CA products, but that
does not mean we should not remove it.

Clint agrees with Ryan and the current draft as it stands.

Dimitris says that according to new revocation policy Mozilla, if a CA
receives a key compromise with POP of private key, then the CA is forced to
revoke all certs with that key.  The "best" way is via SHA256 hash of SPKI
of the key  info (vs. SKI).

Ryan agrees, the best way is via hash of subject public key info globally.

Dimitris said that CAs can use SKI internally since they know how it was
created, so that is not an issue if CAs want to do that.

Tim said that in the longer term CAs should rely on a cert database vs.
content of the certificate where you can have these additional "search"
fields.

Ben supports the current ballot and said we should work to notify CAs that
this is no longer suggested and may eventually want to prohibit the use of
SKI.

Ryan said that both TLS and CA certificates should not include SKI.

Ben said that he'd prefer to keep SKI in the CA certificates

Cory: Summary: Keep current language.

3) Profile ballot: CPS Qualifiers

The current ballot said CPS URI Qualifiers is Not recommended

URI in ICA - OK with Ben, but does not see value in this in the TLS
certificates

Ryan said that very few people even open up cert details and nevertheless a
URI for a CPS URI, what's the value of including this in CA or TLS
certificates. 

Wayne thinks that most CA certificates carry a CPS UIR and as such,
including in the TLS certificate is of little value (both TLS and CA
certificates are provided in the handshake).

Trev is a fan of removing this because she's a fan of making things smaller.
Whenever someone wants to find this, they generally go to the repository for
the CA vs. looking in the certificates.

Clint said we should move away from this, so agrees with the current ballot.

The current ballot says "not recommended" for CA certificates.

Cory: Paul was going to put together a PR for this with the position on
this, so let's proceed with the current language unless someone has further
input.

4) Profile ballot: Order of Subject DN attributes

Doug asked the question on the mailing list about where the ordering
requirement came from.

Tim said it comes from RFC 5280.  Imposes partial ordering on subject info
for location settings, but is OK with relaxing 5280 rules. As far as if this
is important or not, the answer is generally "no".  Mostly imposes order on
geographic fields to have them in a coherent order.  For other fields it's
rather complicated to see there is an order specified.  One the point of
this ballot is to more clearly specify the requirements for order so we can
all comply, but is also open to relaxing the 5280 rule.

Clint said that there were some reasons for ordering from prior discussions
here: https://github.com/sleevi/cabforum-docs/pull/36/files#r872103477
<https://avanan.url-protection.com/v1/url?o=https%3A//github.com/sleevi/cabf
orum-docs/pull/36/files%23r872103477&g=ZDY2MDdhM2NmM2UyYWEzOQ==&h=ODI0ZWU3MW
E5ZGY2NjhkYTc1NDZjZjU1YjliMDY0NGRhYjA2MGJmMDVlY2M5MjliM2ZiZjEwOTliY2ZiMzk5Zg
==&p=YXAzOmRpZ2ljZXJ0OmE6bzpmZmNjOTUwNjNlZjIwOTAyNGM4NmQxMTg1MDFiZDcwNDp2MTp
oOkY=> .  There is some value in specifying this more clearly.  There is
some flexibility we could put in, but it seems reasonable to set ordering so
it can be consistent and relied upon.

Dimitris was OK with the ordering of the location fields, but what about
custom OIDs (JOI OIDs for example)?  Impose order on those that make sense,
not for others.  This may be problematic for CAs to implement.

Martijn said that the current proposal is that some fields need to be
ordered and others do not.  There are 2 tables in the ballot

Tim: This only addresses order of some fields and not all, so not a huge fan
of this since this ballot is only partially ordering the fields.

Corey pointed out that there are 2 tables of attributes in the profile
ballot, the first one (location related) specifies the encoding and order
and the other one does not specify any ordering requirements.

Wayne: Is there an implementation date for this specificity requirement?

Yes, the global transition timeline is defined for all changes, so this is
the same as all changes.

Clint: This portion of the ballot has been stable for a year, so hopefully
people have had time to review and understand this requirement 

Tim: Most CAs and certificate consumers don't historically read ballots till
they are up for discussions, unfortunately.

Clint: This is why we want to get this out as a draft ballot soon and into a
formal discussion period

Tim: This is why we should change discussion period to be longer (90 days
perhaps) and this would help get the last set of good reviews by all.

4) LEIs

Eva said that LEIs area  supported registry scheme by the ETSI but not by
the EVGL.  Can we add LEIs as a registration scheme to EVGL?

Dimitris: Discussed a few meetings ago.  S/MIME BR language can be used for
EVGL and even the BRs.

Tim: Same text "about" the same as a prior ballot.

Tim suggested using the S/MIME version.  What about certificate consumers,
do they have any input?

Ryan said that he has no blocking concerns but remains weary of including
fields that result in mis issuances like misspelling names of locations.  If
this is important for customers, it's not something he will stand in the way
of.

Tim: Hopefully this will improve that.  This is a globally unique value
which should disambiguate identities.  LEIs is a path forward to getting rid
of other unique identifiers.

Clint, as a certificate consumer thanks the group for highlighting this
early.  Not supporting or pushing for this but not resistant to this either.
Wants to see how this goes for S/MIME, but if CAs want to roll this out in
EV TLS certs, that is acceptable.  LEIs could play a role in fixing how we
identity unique organizations globally.

Tim: Also removes divergence between SMIME and TLS groups and also European
requirements vs. BRs.  So solves a few problems.

Ryan: Once this is permitted in EVGL, is there a path that would limit or
remove other JOI fields?

Tim - yes, we can have those discussions.

Tim said that 3-4 years ago did a draft ballot, but we should use a new
ballot based on the S/MIME ballot.

Doug asked if this should be limited to EVGL or if we should include in the
BRs also.

Eva: In theory you can include in OV, optimally in OV if you have the
"info".  Is there an appetite to solve this?

Dimitris said yes.  If a CA wants to follow EV rules and issue an OV cert
for some reason, then that would be acceptable.

Consensus: is it to include other schemes as well, or just LEI?

Dimitris - we can allow org identifier in OV (optionally).  It's not
prohibited today, but it is more responsible to include rules for including
that.

Eva - let's try that then.  Dimitris and Eva to work on that.

Final conclusion: Corey said we'll have a concrete proposal to review soon

5)   "Applicant" and "Applicant Representative related updates

Next meeting we'll continue discussion of "Applicant" and "Applicant
Representative", BR section 9.6.3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230112/1761bc7c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230112/1761bc7c/attachment-0001.p7s>