[cabf_validation] Agenda

[Ryan Sleevi]

On Thu, Apr 9, 2020 at 3:41 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan provided this link to navigate to the proposed certificate profile
> Google Sheet:
>
>    - https://wiki.cabforum.org/validation
>
>
>
> I made some edits to the Root CA and the Distinguished Names sheets by
> adding some columns which I’d recommend we use over the ones Ryan quickly
> specified.
>
>
>
> Perhaps the most “dramatic” recommendation is to split complicated
> compound requirements which are currently stated like this:
>
> MUST contain the Subject’s locality information as verified under Section
> 3.2.2.1. If the subject:countryName field specifies the ISO 3166-1
> user-assigned code of XX in accordance with Section 7.1.4.2.2(g), the
> localityName field MAY contain the Subject’s locality and/or state or
> province information as verified under Section 3.2.2.1.
>
>
>
> Into 2 statements (columns):
>
>    1. Is this a required or optional field and how to you tell?
>    2. Validation rules for when it is present
>
>
>
> So the above would be something like:
>
> Required/Optional:
>
> Required if subject verified under Section 3.2.2.1
> Optional when Country code = XX
>
>
>
> Validation rules:
>
> The Subject’s locality information as verified under Section 3.2.2.1
>
> If I got this right, this is so much easier to interpret.
>

Yeah. This is something that I think is useful and which I'm glad to see
you propose! I think the compound requirements mostly tie to the DN, which
is why I'd been careful of splitting it out, but you're right that after
looking through the whole profile, "required" is a common thing throughout.

That said, there's an added nuance, which is in addition to "Validation"
requirements (which I agree should be a separate column), there's also
"Encoding" requirements. An example of this is whether or not the DN can
contain multiple AVAs within an RDN (they can't, because the AVAs aren't
semantically equivalent, but we should state that). There's also potential
intersections for things like "If a CA includes streetAddress, MUST they
include the other fields" (for a Root CA). So we still probably have some
sharp edges to work through.

There's also some similarity to the "encoding" / "validation" split for
extensions, since some extensions are complicated by having repeated
fields. A good example of this is certificatePolicies, where there's at
least one required value, but CAs can include additional values, and
there's also optional fields with specific validation requirements if
they're present (e.g. cPSUri). An example is whether or not the CA is
*only* permitted to have an HTTP cPSUri, or if they can have an HTTP cPSUri
and also other URIs.

But overall I think your refinements are good and welcome :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200409/c1856458/attachment.html>