[cabf_validation] 2021-03-11 Meeting Minutes

[Ryan Sleevi]

Validation Sub-committee draft minutes for 2021-03-11

## Attendees

  * Douglas Beattie
  * Corey Bonell
  * Niko Carpenter
  * Michelle Coon
  * Janet Hines
  * Andrea Holland
  * Tim Hollebeek
  * Daniela Hood
  * Rebecca Kelley
  * Bruce Morton
  * Trevoli Ponds-White
  * Ryan Sleevi
  * Curt Spann
  * Wayne Thayer
  * Paul van Brouwershaven
  * Ben Wilson
  * Clint Wilson
  * Dimitris Zacharopoulos

## Agenda

* Profiles
  * Naming
  * Key Usage
  * Subordinate CAs
  * End-Entity Certs
  * Country validation
  * Formatting
  * Multiple attributes within names
* 398-day proposal

## Profiles

Ryan began with presenting his current work in progress converting the
profiles work into Markdown and the BRs, as well as sharing some of the
challenges or open-questions.

### Naming

The first was the area of naming, in terms of what attributes can be
included in certificates, what their permitted values are, and how those
requirements should be expressed. The BRs today currently have a variety of
permutations that can vary. For example, Root CAs and Subordinate CAs
aren't permitted to use "XX" for country, where Subscriber certificates
can. Another oddity is that for Root and Subordinates refer to Section
3.2.2.3 for countryName validation, but 3.2.2.3 is an extension of 3.2.2.1
that permits using the country associated with the domain or IP, which CAs
don't necessarily have.

Another situation was today the BRs only require certain fields for
Root/Subordinate CAs, but permit other fields. Names are hierarchical, and
so wanted to try to express requirements in terms of the order of how those
names are expressed. Tim pointed out that the order of postalCode is
probably sorted incorrectly, as it's a larger area than the streetAddress
field.

Ryan then showed how the requirements for fields and their encoding are
expressed, which is in a separate section, and tried to incorporate
feedback from previous calls in capturing requirements like field lengths
and where the relevant definition of the field is (e.g. X.520 vs RFC 5280)

He described introducing a requirement for how names are encoded, to ensure
only one attribute is encoded in each RelativeDistinguishedName.

### Key Usage

The next area Ryan discussed was how we handle options and permutations. He
showed the example of Key Usage, which has two variations for a Root CA,
depending on whether or not the Root CA issues OCSP responses. The general
problem is trying to figure out which options make sense as a distinct
certificate profile, and which may make sense as just an option within a
section. Ryan opted for an approach for Root CAs to keep it just in key
usage, but could also be convinced to split into separate profiles.

Tim pointed to the current draft text, highlighting that the requirement,
based on what the CA will or won't do in the future, is tricky. Ryan was
mixed: at time of creation, the issuing CA is making a declaration about
what they will or won't do, so there's some requirement there. He
highlighted another example with Sub CAs, in terms of whether or not they
will issue TLS certificates, so that's where the language was borrowed.

Tim suggested an alternative approach, which would be "If the
digitalSignature bit is set, the CA will issue OCSP responses. If the
digitalSignature bit is not yet, the CA SHALL NOT issue OCSP responses."
Dimitris was not sure about this proposal, highlighting that the CA may set
the digitalSignature bit, but then decide not to issue OCSP responses, and
that should be fine. Tim modified the "will" to "MAY" to address this.
Trevoli was concerned the current approach makes the section seem more like
a recommendation: "Don't include this if you don't want to use OCSP".

Ryan agreed with these concerns, and this language wasn't final. The
example of OCSP issuance based on the digitalSignature bit may fit better
in the OCSP Profile section, which wasn't something we'd planned to start
yet.

Quite a bit of this was just trying to get feedback on the approach. For
example, an alternative would have been displaying key usages in a table,
rather than a bulleted list. If we do that, do we list every key usage and
say "Don't include", or do we just list what's permitted? Curt said he had
a light preference for tables, even though that can be tricky to format
nicely, so could live with the bulleted list. Ryan said he'd convert to a
table to get folks' feedback on the approach.

Curt asked for further clarifications on what approach Ryan was suggesting.
Ryan said there were several ways we could structure this section. The
least ambiguous, most programatic way would be to express the extension as
an exact byte sequence, since there are only two permissible encodings.
This is what we did for SPKI, but is probably the least accessible to read.
Another approach is the approach he currently took, which was displaying
requirements as a bulleted list of what MUST be set, with everything MUST
NOT be set. Another alternative would be a table, but with just a single
column, of what key usage bits MUST be set, with a requirement to MUST NOT
anything not mentioned. The last alternative is a two-column table that
lists each keyUsage bit, along with a second column that indicates whether
or not it's permitted.

Curt suggested the last option was perhaps most clear, and so preferred
that. Ryan indicated these were just placeholder ideas, and would update
this section.

### Subordinate CAs

Another area that Ryan had been struggling with is how many permutations of
sub-CAs we have. One dimension is whether or not the sub-CA is an Affiliate
of the issuing CA or not, since this can affect extensions like
certificatePolicies and extendedKeyUsage. Another dimension is whether or
not this is a cross-cert of an existing root or not, since this also
affects EKU, but also affects subject naming, which is something Doug
Beattie had raised in the past. That is, if you have a root that complied
with the BRs when it was issued, can a CA cross-certify that if the name no
longer complies with the sub-CA naming rules? These seem important issues
to sort out now, especially as we talk about profile changes, even
something like organizationUnit.

Ryan described the scenarios he'd identified:

  - Cross-Certified CA
    - Same Organization/Affiliate
    - Different Organization
  - Technically Constrained Sub-CA
  - TLS Sub-CA (which can vary based on Affiliate status)
  - Non-TLS Sub-CA (which can vary based on Affiliate status)

An example of complexity is a field like nameConstraints, which may be
REQUIRED for some profiles, or MAY for other profiles, and how the content
is validated should be the same across these profiles. Ryan's continuing to
try to explore different approaches for how to best capture this
information.

Dimitris mentioned this was something he's been interested in since he
joined the Forum, and is interested in working through the permutations. He
was familiar with certificatePolicies, but wasn't familiar with the EKU
changes. Ryan mentioned that it's a special case where it's both a
cross-certificate and affiliated, which would allow anyEKU, which might
otherwise be restricted.

Dimitris asked whether it would make sense to have a separate section for
cross-certificates by separating from sub-CAs. Ryan mentioned it's not just
cross-certificates, but he is exploring making it clear that
cross-certificates are a type of sub-CA. He was nervous about suggesting
cross-certificates were different from roots or sub-CAs, especially because
the requirements we have in other sections are all based on Root CA or
subordinate CA. There was some discussion with Doug Beattie on the list a
year or two ago about this problem, and Ryan is attempting to try to
explore options for clarifying that. Doug agreed that different types of
subclasses make sense, since it helps keep our other sections, like audits,
simple.

Bruce asked about the proposed language for cross-certificates, and whether
the idea is that the name of the cross-certificate needs to be identical to
the root certificate, rather than having rules on the name for that
specific class. Ryan said that he was trying to work through this: you want
to make sure the name is identical, but you want to make sure someone can't
just create a self-signed root and use that to get around sub-CA naming
requirements. So the idea is that if you have a root that was compliant
with the BRs or a previous version of the BRs, it'd be fine, but wanting to
make sure the name was created subject to the BRs at some point. Ryan said
this would be easier if we'd resolved the audit lifecycle issues we'd
talked about previously, but since we haven't done yet, he's still working
through how to solve this.

Curt mentioned that an approach to handling these classes might be to have
one table that is common to all the requirements for such sub-CAs, and then
have additional tables that introduce specific requirements for each type
that are above-and-beyond. He wasn't sure if that made more sense than
fully enumerating all of the requirements for each type, since that could
end up repetitive. Ryan agreed that this is the problem he's been
struggling with, and is exploring options.

One option he was exploring was having full tables for each profile, but
have the requirements column refer to a common section for where the
requirements are shared between multiple profiles. Another option was
similar to what Curt was suggesting, which would be multiple tables within
a section covering each permutation, with a table label, and each table
only has 2-3 rows for what's different.

### End-Entity

Ryan hasn't yet finished end-entity certificates yet, and so doesn't have a
demo to show. However, the problems are similar to what we just discussed
for sub-CAs. We have variations between DV, IV, OV, and EV. DV varies on
how the country is validated, both from CAs, and because it allows Section
3.2.2.3. IV allows additional attributes, but some of them don't make
sense. For example, streetAddress is required to be validated against
Section 3.2.2.1, which is for organizations, rather than 3.2.3, which is
for individuals. While you probably don't want to include a streetAddress
for an IV cert, we should fix up the validation requirement, which is right
now inconsistent with the Certificate Policies section that said validated
against 3.2.3.

Similar to sub-CAs, he's exploring how to express these requirements in a
way that makes sense.

### Country validation

The last situation was where the country name doesn't have an ISO 3166-2
country code assigned, and so we use XX. He had examined CT, and saw it was
only Sectigo and DigiCert that had issued such certificates. With our
current requirements in 7.1.4.2.2, we have a number of permutations, in
which the countryName contains XX, but then the stateOrProvince may be
absent, may contain the state or province, or may contain the country.
Locality is the same, and this results in 8 different permutations for the
contents of the field here.

The discussions seemed to reach consensus that stateOrProvince should be
state or province and locality should be locality. Whether we introduce a
new attribute, and whether that attribute is optional or required, has
different tradeoffs, and probably needs further discussion. But this would
be a change to try to simplify the requirements between all these
permutations by having consistent field contents. At most, the permutation
would be the naming for XX names and the naming for non-XX names.

### Formatting

Trevoli pointed out that, on the topic of readability, have we given any
thought to changing the font? Ryan said yes, that's totally something we
can do, and wouldn't necessarily require a ballot. A big part of the
infrastructure work was, in fact, in getting fonts working, since the EV
Guidelines have some CJK fonts and getting everything working was a pain.
However, we can change the fonts to whatever we want. Ryan just used the
fonts from our existing word template at the time. The only real
requirement is for freely distributable fonts.

Trevoli suggested she could join the infrastructure group to discuss
further, but was keen to find a font that was readable. Ryan mentioned he
used Google Fonts for these, but any foundry or freely distributable font
should work.

### Multiple values within names

Ryan said the current draft language attempts to restrict there to being
one instance of a given attribute within a subject name. For example, a
certificate with multiple country names doesn't make sense. However, there
was one exception, with streetAddress, which has a 128 character limit. If
CAs are including the streetAddress, and the address is longer than 128
characters, should they be able to include multiple streetAddresses?

Ryan said it's no secret that Google would like to see identity information
moved out of TLS certificates, into a separate set of certificates.
However, since that's not yet required, he wanted to provide guidance for
CAs on what to do in the interim. He wanted to get feedback from folks on
whether or not folks agreed that streetAddress was the only field that made
sense.

Tim said he recalls it being discussed internally at DigiCert, but doesn't
recall beyond that, and would need to look for further details. Ryan
mentioned Sectigo recently announced they were removing streetAddress, in
part to resolve ambiguities like this, which is good. Ryan continues to
look through for these sorts of exceptional situations to try and flag for
discussion, as well as see if folks had strong feedback.

Dimitris said he thinks folks probably have strong feelings on what fields
should only have one instance. But perhaps for fields not listed, it can be
left only as a SHOULD. Ryan was concerned with this, because he wasn't sure
if the current BRs language could be read as being permissive, and there's
also a host of challenges in properly encoding multiple fields, so he was
keen to be more explicit for when multiple fields are allowed.

Tim said if CAs looked through their systems, they'd probably find they
don't actually support multiple fields, except for perhaps streetAddress.
Ryan shared some of the existing proposed language, which includes a
carve-out to explicitly permit multiple fields when we want to be explicit
about it. It might be OK to allow for custom attributes, such as a
customer-specific OID, for as long as we allow customer-specific OIDs.
However, including multiple attributes within one SET is silliness he wants
to prohibit.

### Closing

Ryan indicates he continues to work through these edge cases, and reaching
out to CAs that might be affected by different situations. He's not trying
to cut folks out of discussion, but trying to make sure to minimize impact
in the proposals, before we get to the broader discussion. He hopes to have
a version before the next call, so that it can be more closely reviewed.

## 398-day domain validation requirement

Daniela had a question about the draft ballot Ben Wilson had circulated
regarding changing the domain validation requirement. It sounded that
during the F2F discussion, but perhaps this was a misunderstanding, there
had been a proposal from Dimitris to change section 4.2.1 to change
everything to 398 days, including data reuse.

Ben and Dimitris clarified this was just for domain and IP address, while
leaving the other information at 825 days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210324/e0b93d27/attachment-0001.html>