[cabf_validation] Draft Minutes for Validation Subcommittee Teleconference - 19-November-2020

[Ben Wilson]

Here are the draft minutes of our teleconference yesterday.

Validation Subcommittee Minutes

Thursday, 20-Nov-2020

*Attendees:*  Ben Wilson, Wayne Thayer, Amanda Mendieta, Enrico Entschew,
Clint Wilson, Johnny Reading, Ryan Sleevi, Tim Hollebeek, Shelley Brewer
Wendy Brown, Paul van Brouwershaven, Janet Hines, Joanna Fox, Aneta
Wojtczak, Daniela Hood, Michelle Coon, Corey Bonnell, Julie Olson, Trev
Ponds-White, Andrea Holland

*Review agenda*:  Today we’ll review the certificate profile that Corey has
converted into tables in markdown format.

*Antitrust Statement* – Read by Wayne Thayer

*Discussion*

Corey shared his screen. He has taken the profile and put it in a table
format in markdown in Github.  He asked whether we should go over Ryan’s
comments.

https://lists.cabforum.org/pipermail/validation/2020-November/001592.html

Ryan – Extensions are complex fields that need to be broken out. We want to
show what is and isn’t permissible.  For example, in certificatePolicies,
we want to show whether policy identifiers and qualifiers can be used and
what are the rules for validation. Or, subjectAltName, where there are many
different name types.  For example, the Spanish CAs were using the DER name
in subjectAltName, and as currently written in the BRs, it’s not allowed.
The permitted values column can be the source of some confusion. The
allowed values need to be broken out and for all content, we need to be
very precise for each of these fields.

Corey – Nested tables are hard to do.  We can use nested tables in a
table-based profile.

Tim – I agree with Ryan.  Also, doing in sheets with sub-rows will be
complex and confusing.  We should break these into separate tables for
SANs, other extensions, etc.  It would be better than a wall of text.

Ryan – We can break down the subjectAltName, and an example of an
extra-complex field is the certificatePolicies extension. We could have a
single section called Certificate Policies, and we could have multiple
tables within that section.

Tim – Let’s say that there are dependencies in a complex table, like
putting a policy qualifier in an OV certificate.  Then, instead of putting
an “if” in the qualification, we say that there is a dependency based on
the type of certificate you are creating. EV vs. OV vs DV etc.

Ryan – We need to make it unambiguous. I recognize that Github markdown is
difficult. It also changes some of the styles when rendered. There is white
space, and we need to improve how it is output in PDF or DOC.

Tim – Visual Studio Code might work as a WYSIWYG MD editor.

Corey – We need to come up with a solution for markdown and nested tables.

Ryan – With IV certificates, there are if-then issues for IV names.  Given
name, surname and organization name – could be captured in two or three
tables.  There are also the issues with country code XX where
state/province and locality combinations shift that need to be explained in
tables. Everything that is dependent on the relationship needs to be
expressed (organization name present, etc.)  Does this make sense?  There
would be three tables for names and three fields/tables for country name
(when it is and isn’t XX), state/province fields, and locality fields. He
will create a pull request in Github to make it more visual.

Regarding the free-form text … specifically the last column at the end on
the right of the table – the specification references and the content in
the specification references, I think we can fold the OID column into the
same column of the table.  Working from left to right, we can include
country name and OID in the same column, and make other changes to the
columns on the right.  The ASN1 type fields appear a little duplicative.  We
can collapse the last three columns on the left into two columns with one
having the allowed content and the other having the validation required.
How do people feel about the ASN1 column and the reference column?

Corey – Discussed the rationale for putting in the ASN1 and references
columns.  For the subject name fields they are helpful.  There have been
discussions about the lengths of fields and street address and postal codes
some time ago.  Some values come from places other than RFC 5280, and
references help avoid having to dig down through several levels of
documents to find that the reference actually comes from X.520, for example.

Tim – Traceability information is very helpful. If the references are
taking up too much horizontal space, then comments could be placed in the
markdown document, but I don’t know if I like the markdown document having
more information than the published document.  We ought to make it also
clear, for example, how many characters can be used.  The column says 128
characters, but for someone unfamiliar with the standards, is that 128
displayable characters or multi-byte characters?

Ryan – According to RFC 5280 they are supposed to be a UTF8 string. We need
to distill some of the relevant goals here.  Does it make sense to have an
appendix for places where we allow things beyond RFC5280 and X.520, in
extensions (e.g. CABF OIDs, CT, etc.), and putting references there for
distinguished name fields?

Tim – Likes the idea of stashing information in an appendix and putting
information that is more helpful in the table -- take deep dives out of the
table.

Wendy – Can we include that short reference in the ASN column in
parentheses underneath that and combine it with the references column?  And
not eliminate them from the table.  Having the reference right there is
still useful, regardless of whether we have an appendix for more
information.

Tim – Perhaps some of the RFC 5280 references could be dropped or condensed.

Ryan – Part of my reasoning for thinking of the appendix is that CAs should
already be fully using the ASN module.  Using the ASN1 module should
resolve issues like this.  They should be using the ASN1 generator.  So we
really need to focus on the contents and the validation, that is what was
behind my thinking on this.

Wayne asked on chat:  Does that put us back in the situation of having to
look in multiple locations to get all the information required to meet a
requirement?

Ryan – Yes – it moves information. I don’t think it’s something that CAs
will be looking at, because if they have to look at it, they should already
have something in place. The normative part is RFC 5280.

Tim – I think they’re both important for multiple parties who might refer
to the document. If I have to refer people to ASN1 modules, that makes my
life much more difficult.

Ryan – I can see that value. I still think specification references should
be in an appendix.

Tim – One idea for an organizing principle is that all of the “what” should
be in the tables.  Informatives and “whys?” are non-normative and belong in
the appendix.

Corey – One reason to put the ASN1 type in here, as Ryan alluded to, is you
are not supposed to use anything but printable string and UTF8.  Later we
can replace this directory string with explicitly printable string or UTF8
string.  We could be more restrictive than the ASN1 types.

Ryan – That’s a reasonable argument for the distinguished name, but not as
important for TBS certificate.

Tim – I don’t want to lose the ASN1 type. I don’t think it is that similar
to the references section. The level of sophistication of the people
reading this document will have a wide range.

Ryan – This does not need to be a guide for how to become a CA because the
level of sophistication goes way beyond this.

Tim – There are a lot of gotchas here, and there are people other than CAs
who would find this useful. So we ought to be careful about throwing away
information that makes it more understandable for people who are less
familiar with certificates.

Ryan – I disagree.  This should be a profile.  I see the value with the
directory string for distinguished name, and equally for field length, but
when it comes to certificates and extensions, I am more reserved. It should
be for CA compliance teams to explain what the validation requirements are
and to derive an acceptable set of tests from it.

Tim – I would like the table to be explicit about everything so that people
can determine what the DER-encoded bytes are and that they are correct
without having to chase references into sections of RFC 5280, especially if
we are going to take the references out of these tables, which will make it
harder to chase the references.  If we are going that direction, then the
tables need to be more free-standing. I don’t want the information to be
lost.

Ryan – I don’t share the goal of being able to go from table to DER-encoded
bytes. I want to see validation requirements and whether that information
can go in here or not, without getting into the encoding.

Wendy said on chat: I would like it to be crystal clear if a "limit" is
from a standard vs just imposed by CABForum.

Trev - agrees with Wendy.  We should be clear about who the audience is for
this table.  This should be clear for CAs and clear for customers when they
disagree.

Tim – External specifications will make people less upset.

Trev – What about having examples? Maybe on the website for how this thing
should look.

Tim – That’s good, but then people will argue that something can’t be done
because it doesn’t follow the example.  I agree with both sides of the
argument.

Corey – Appendix C of RFC 5280 has examples.  I’m not sure that we want to
get into this level of specificity, but we could include dumps of
certificates.

Tim – We could reference lines from that appendix rather than creating our
own.

Ben asked on chat:  Why can't the table be landscape-formatted rather than
portrait style?

Ryan – As soon as we get a process in place on GitHub, we can control how
it looks in PDF and DOC. Other markdown renderers don’t impose that block
of horizontal white space that we see in Github. Jos and I are working on
it.

Meeting adjourned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201120/ad1ce362/attachment-0001.html>