[cabf_validation] Final minutes for the VSC Teleconference - September 5, 2024

Fri Sep 20 18:10:55 UTC 2024

These are the Final Minutes of the Teleconference described in the subject
of this message as prepared by Chris Clements and approved on the 2024-09-19
meeting of the Validation sub-committee.

Meeting Date: 2024-09-05

Attendees:

Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Ben Wilson (Mozilla),
Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey
Bonnell (DigiCert), Corey Rasmussen (OATI), Doug Beattie (GlobalSign),
Dustin Hollenback (Microsoft), Gurleen Grewal (Google), Iñigo Barreira
(Sectigo), Johnny Reading (GoDaddy), Joseph Ramm (OATI), Kiran Tummala
(Microsoft), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft),
Martijn Katerbarg (Sectigo), Michelle Coon (OATI), Nargis Mannan
(VikingCloud), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Puja
Sehgal (Microsoft), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Ryan
Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Steven
Deitte (GoDaddy), Sven Rajala (Keyfactor), Thomas Zermeno (SSL.com), Tobias
Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer
(Fastly), Wendy Brown (US Federal PKI Management Authority)

1. Meeting Open:

- Corey Bonnell opened the meeting, read the note-well, and completed the
roll call. 

2. Minutes:

- Minutes from the last meeting (August 22, 2024) were approved.

- Corey shared the current list of minute takers and asked for any additions
or removals. One person was added.

3. Next Meeting:

- We’ll discuss F2F planning in the next meeting.

4. Agenda:

- Only one topic planned for today, which continues the development of the
STRIDE model for method #7.

- Paul van Brouwershaven sent a message to the Validation distribution
before the meeting:
<https://lists.cabforum.org/pipermail/validation/2024-September/002028.html>
https://lists.cabforum.org/pipermail/validation/2024-September/002028.html 

5. Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing
certificates:

- Paul introduced the topic where “[...] at least one Reserved Certificate
Policy Identifier” is stated in section 7.1.2.10.5 of the TLS BRs and RFC
5280 says “Object Identifier”, possibly implying only one Identifier.
Further, under the Policy Restricted table in 7.1.2.10.5 there is language
that states: “[...] the Certificate Policies extension MUST contain exactly
one Reserved Certificate Policy Identifier.” This statement makes sense if
referencing an Issuing CA, but in the context of a Cross-Certified CA it is
not specified. His interpretation is that you cannot create a
Cross-Certified CA that is constrained on TLS DV, OV, and EV policies. Is
this interpretation correct and if so, was that the original intention of
this language?

- Martijn Katerbarg previously identified this contradiction and created an
issue in GitHub ( <https://github.com/cabforum/servercert/issues/539>
https://github.com/cabforum/servercert/issues/539). He suggested that the
language in the table be updated because minimally this is confusing.

- Paul stated there are a few CAs issuing these certificates. Based on
recent discussions nobody can issue Cross-Certified CAs at the moment and
those that are already issued may be misissued. Is this an error in the
document? It seems like the only approach is to cut multiple Cross-Certified
certificates to avoid this problem, but there are people out there that have
this problem. 

   - Martijn clarified this is only true if the CAs are Non-Affiliated.
Affiliated CAs can use the anyPolicy. 

   - Paul suggested even if it is an Affiliated CA you may want to use the
policy restricted cross-sign. 

- Corey also identified this when writing the profiles cleanup ballot last
summer. In his opinion, restricting Cross-Signed certificates or CA
certificates in general to just one Reserved Policy Identifier was not
intended. He believes this language is a copy/paste error from the
Subscriber Certificate section, where it makes more sense. 

- Paul suggested he draft a ballot to correct the language. Does this mean
for the time being you cannot issue Cross-Certified CA certificates?

   - Wayne Thayer asked for clarity that you can issue a Cross-Signed CA
certificate but it can only include one Reserved Policy Identifier. Paul
confirmed this is correct.

- Clint Wilson agreed with Corey and believes the sentence was supposed to
say something like “the Policy Qualifiers field must contain exactly one
Reserved Certificate Policy Identifier”, since that is also what RFC 5280
states. It seems as if new Cross-Certified CAs are issued right now with
multiple Policy Identifiers then that would be not compliant with the way
this is stated, unless you can use the no policy restrictions for Affiliated
CAs. It seems like we should pass a ballot to correct this. He suggested
reviewing historical conversation to try and determine original intent. The
specific sentence of “[...] MUST contain exactly one Reserved Certificate
Policy Identifier.” doesn’t seem appropriate in its context.

- Aaron Gable referenced the PR description (
<https://github.com/cabforum/servercert/pull/373>
https://github.com/cabforum/servercert/pull/373) calling attention to: “For
CA Certificates, a new requirement that the Reserved Certificate Policy
Identifier be the first policy identifier present. Although this is not
required by RFC 5280, multiple applications have implemented logic that
extracts the first matching/known policy identifier from a certificate, when
computing special policies (e.g. EV treatment). Ensuring the Reserved Policy
Identifier is first reduces the risk of improper classification of a
certificate. As this only applies to new CA Certificates going forward, it's
phased in with immediate effect.” There does appear to be some intent here
that there be only one Reserved Policy Identifier and it be the first of the
Policy Identifiers in the certificate. He suggested “should only have one
Reserved Policy Identifier" because clearly there are existing CA
certificates that have DV, OV, and EV Identifiers in them and he doesn't
think there is anything particularly wrong about this. He is less convinced
the existing language is a typo. 

   - Corey believes the summary language was a bit out of date compared to
what was actually in SC-62, because originally it was a hard requirement
that the first Policy Identifier be a Reserved ID, but that got relaxed to a
“should” in the final language. 

   - Trevoli Ponds-White suggested Ryan Sleevi previously said Chrome
ignores all Object Identifiers after the first one, so if you wanted EV
treatment the EV OID had to be first. Ryan Dickson stated that is incorrect.
Ben Willson suggested this was actually a Mozilla issue that they resolved
and might have been the reason the requirement was relaxed. 

   - Clint suggested that it makes sense to issue separate Sub CAs for each
type of certificate being issued, at which point this requirement does not
prevent the issuance of those Sub CAs, but either way we need to get clarity
on the intent and how that's supposed to be handled by CAs. Trev suggested
the intention was driven by what Browsers do. Clint confirmed that ordering
might have been a driver, but whether or not you could have more than one
Reserved Policy Identifier was not. He could see this being useful to have
separate certificate types issued per CA. Paul suggested that maybe the
intent was directed towards dedicated Issuing CAs. Trev stated the intent of
the ballot was to make things more clear and if we introduced something that
creates confusion, then we should clean it up. Clint stated the intent was
also to ensure that there were clear boundaries for what each type of
certificate was and that every certificate type that could be relevant to
the TLS BRs was present. 

- Martijn does not see an issue with the language if it relates to normal
Subordinate CAs and limiting them to just one Reserved Policy Identifier,
but Cross-Signed CAs is an exception case and he suggested copying
7.1.2.10.5 to a new section called Cross-Signed CA Certificate Policies and
have slightly relaxed text there. 

- Clint suggested that Subordinate CAs only have one Reserved Policy
Identifier. It's not clear as to why a Subordinate CA between the Root and
Issuing CA would need to have multiple Reserved Policy Identifiers. Paul
reiterated his focus is on the Cross-Signed CA.

- Ben stated he would support a ballot that treats this language as a
mistake and allows a CA certificate to have multiple Reserved Policy
Identifiers. Clint clarified that there are reasons why this might not make
sense for all CA certificates, but it does for Cross-Signed CAs. Ben
suggested otherwise CAs have to create multiple Sub CAs.

- Doug Beattie highlighted that there is already a section for
Cross-Certified Subordinate CA Certificate Profile in 7.1.2.2. Maybe we just
add a Certificate Policy subsection there to indicate a special role. 

- Corey stated we already allow anyPolicy for CAs and if we wanted specific
Reserved Policy Identifiers per CA we would need a prohibition on anyPolicy,
which would be a pretty big change for the ecosystem. 

- Clint stated removing anyPolicy was slated for Profiles v2.0 and retaining
it in the profiles was more of a compromise at the time. This does need to
be removed if we want to have fully clean profiles.

- Corey suggested proposing a ballot that only addresses the Cross-Signed
CAs case. When we review profiles more holistically we can potentially have
a ballot that addresses all Sub CAs. Clint suggested in the meantime,
multiple Cross-Signed Sub CAs could be created. One with each policy. The
current language does not block this, it's just less convenient. 

- Paul suggested the easiest approach would be to adjust the language in
section 7.1.2.10.5, rather than copying and creating a new section. 

- Corey preferred duplicating the content because that is what is done
throughout other sections. One thing that comes to mind is basicConstraints
for CA certificates. It’s largely duplicative text for the root CA versus
every other type of CA certificate, where basically one element is
different, but the rest of the text is the same. Clint leans towards copying
and pasting.

- Paul will draft a ballot that adjusts the Cross-Signed CA Profile Policy
OIDs and circulate that on the list.

- Clint referenced a commit
(https://github.com/cabforum/servercert/commit/a0360b61e73476959220dc328e3b6
8d0224fa0b3) calling attention to: “Make PolicyIdentifier ordering optional.
This makes the requirement for the Reserved Policy Identifier to be the
first policyIdentifier optional, while explaining with a note the basis for
that logic. To avoid confusion, it makes it clear that only one instance of
a Reserved Policy Identifier may be present (e.g. can't be simultaneously OV
and EV)". The intent seems clear for the general case of CA certificates.
Generating multiple Cross-Signed CA certificates also seems appropriate. 

- Martijn thought multiple Sub CA cross signings is prevented by the subject
naming which has to be byte-for-byte identical both in Issuing CA and
Subject CA. It depends on interpretation. Paul suggested it would mean you
could have multiple signing certificates with the same key and the same
subject but only different policies, which would be really hard to identify.
Corey’s recollection of SC-62 was that Microsoft Windows had some type of
Sub CA cacher and it used the key ID as the identifier for that cache. If
you have multiple Cross-Signed CAs floating around, same subject DN, same
key identifier, and differentiated solely on policy, whether or not that
would confuse the cache. It seems like this could introduce potential
complications and operational issues for some environments. 

   - Clint stated there are a lot of CAs with the same key and name with
minor differences. There is one pattern where a large number of CAs are
duplicated with only the AIA being different between the two CAs. We have
not seen any issues with those. If CAs have seen any issues, that would be
interesting to know. 

- Corey summarized that the next step is a ballot to allow multiple Reserved
Policy Identifiers for Cross-Signed CAs and we’ll look holistically at all
Sub CAs at a later time. 

6. Any Other Business:

- None.

6. Next call:

- September 19, 2024

7. Adjourn

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