[cabf_validation] Draft table-based certificate profile definition

[Ryan Sleevi]

On Tue, Nov 17, 2020 at 3:57 PM Corey Bonnell via Validation <
validation at cabforum.org> wrote:

> Hello,
>
> After the validation-wg call a few weeks ago, we started working on a
> draft certificate profile for Individual Validation end-entity certificates
> to see how well the table-based approach works. The initial draft is
> located here:
> https://github.com/digicert/validation-wg-cert-profiles/blob/main/tls.md.
>
>
>
> We think this format is a major improvement over the current text-based
> format used in the BRs, but we’d like to circulate this prior to this
> Thursday’s meeting to gather feedback and discussion points. The normative
> requirements listed therein should be reflective of the information in the
> Google spreadsheet.
>
>
>
> If you note any deviations from the requirements listed in the spreadsheet
> or have any suggestions on how to improve the proposed format and content,
> please raise on the list or on this Thursday’s call. If there is consensus
> that this format works well, we can expand the draft to encompass the other
> certificate profiles.
>

Corey,

Thanks for starting this, and it's good to see this borne out. With
extensions, my biggest concern here is that there's a lot of complexity
hiding in the "permitted values", and I'm not entirely sure this approach
works to reduce that complexity.

Concrete examples:

1. Extensions
  The approach used for extensions is inconsistent with the approach used
for the Certificate, the tbsCertificate, and the Subject, by folding all of
the sub-structure requirements into a single cell. For fields that are
SEQUENCES (e.g. EKU) this makes sense, but I think for some fields, such as
certificatePolicies, subjectAlternativeName, authorityInfoAccess, and
keyUsage this does a disservice.

  Consider, for example, that this approach to subjectAltName leaves it
ambiguous about whether other name types are permitted (they are not), an
issue we don't have with the current language (Also, note that it's
"Subject Alternative Name" or "subjectAltName"; this table confuses those
by removing spaces)

2. IV certificates
  The approach taken here retains the flaw of "if X, this, if Y, that",
which we'd discussed on our previous call as complex here. As mentioned on
the call, we really have two forms of IV subjects (four, counting the XX
country name), and we discussed representing each of those explicitly. More
explicitly, it seems like it should be possible to exactly match any given
subject to one and exactly one table.

3. TBSCertificate
   While this breaks out each field (good), it unfortunately combines
everything into a generic profile. As mentioned on several previous calls,
this also does a disservice, for the same reason mentioned in IV
certificates - a lot of conditional tables. The minutes of our last call
suggested Tim agreed, and that we'd be better off with a single
table-per-cert instead of trying to group these altogether.

That said, I think there's also a material error here, which is not
reflected in the spreadsheet. Apologies if it was incorrectly understood on
a previous call, but the suggestion that LDAP and FTP URLs are appropriate
for AIA fields according to the BRs. I suspect this is, at its heart, a
question about whether the "SHOULD" and "MAY" allow for other values, or
whether it represents a complete set of the allowed values (i.e. you can
include one or both of those values, but no more). This is one of the
things profiles are meant to cover. Taken in light of the above remarks
about "Extensions", I think this gets clearer where, for complex fields
like AIA that have themselves nested extensible structures, we can define
(sub)sections that explore the contents and fields.

>From a stylistic point, I don't think we need the column references here.
That seems unnecessarily superfluous, and I think also invites confusion by
CAs on whether or not certain profiles are implicitly permissive.
Similarly, the ASN.1 type and constraints also seems to be duplicative of
the relevant RFC (especially muddied with references to, say, X.520 in
7.1.4.2.1).

Concretely, I think the columns in 7.1.2.3 are:
* Extension ID (where the row value is both the name and OID)
* Required
* Critical
* Permitted Values (with a reference to a relevant subsection)

In 7.1.4.2.1, I think we've got:
* Attribute (where the row value is both the name and the OID)
* Required
* Contents
* Validation

So, for example, we'd have
Attribute, Required, Contents, Validation
"commonName (2.5.4.2)", "No. Discouraged, but not prohibited.", "See
Section 7.1.4.2.1.x", "MUST be validated as required by 3.2.2.4 / 3.2.2.5"

and
"""
Section 7.1.4.2.1.x: Acceptable commonName values

The following table details the allowed values for the commonName field.

Type, Representation
"Domain Name", "MUST contain the same character sequence as a dNSName that
is present in the subjectAltName extension"
"IPv4 address", "MUST contain the textual representation of an iPAddress
that is present in the subjectAltName extension. IPv4 addresses MUST use
the dotted-decimal form ("#.#.#.#")"
"IPv6 address", "MUST contain the textual representation of an iPAddress
that is present in the subjectAltName extension. IPv6 addresses MUST be
encoded using the canonical textual representation of RFC 5952."
"""
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201117/0e111893/attachment-0001.html>