<div dir="ltr"><div>Here are the draft minutes of our teleconference yesterday.</div><div><br></div><div>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Validation Subcommittee Minutes<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Thursday, 20-Nov-2020<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Attendees:</b><span> </span>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<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Review agenda</b>:<span> </span>Today
we’ll review the certificate profile that Corey has converted into tables in markdown format.
<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Antitrust Statement</b> – Read by Wayne Thayer <br></p><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><b>Discussion</b><br></p><p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey shared his screen. He has taken the profile and put it
in a table format in markdown in Github.<span>
</span>He asked whether we should go over Ryan’s comments.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif"><a href="https://lists.cabforum.org/pipermail/validation/2020-November/001592.html">https://lists.cabforum.org/pipermail/validation/2020-November/001592.html</a><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – Extensions are complex fields that need to be broken
out. We want to show what is and isn’t permissible. <span> </span>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.<span> </span>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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – Nested tables are hard to do.<span> </span>We can use nested tables in a table-based
profile.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – I agree with Ryan.<span>
</span>Also, doing in sheets with sub-rows will be complex and confusing.<span> </span>We should break these into separate tables
for SANs, other extensions, etc.<span> </span>It
would be better than a wall of text.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – Let’s say that there are dependencies in a complex
table, like putting a policy qualifier in an OV certificate.<span> </span>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.<span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – Visual Studio Code might work as a WYSIWYG MD editor. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – We need to come up with a solution for markdown and
nested tables.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – With IV certificates, there are if-then issues for IV
names.<span> </span>Given name, surname and
organization name – could be captured in two or three tables.<span> </span>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.)<span>
</span>Does this make sense?<span> </span>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. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span> </span>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.<span>
</span>The ASN1 type fields appear a little duplicative.<span> </span>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?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – Discussed the rationale for putting in the ASN1 and
references columns.<span> </span>For the subject name
fields they are helpful. <span> </span>There have been
discussions about the lengths of fields and street address and postal codes some
time ago.<span> </span>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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span> </span>We ought to make it also clear, for example,
how many characters can be used.<span> </span>The
column says 128 characters, but for someone unfamiliar with the standards, is
that 128 displayable characters or multi-byte characters?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – According to RFC 5280 they are supposed to be a UTF8
string. We need to distill some of the relevant goals here.<span> </span>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?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wendy – Can we include that short reference in the ASN
column in parentheses underneath that and combine it with the references
column?<span> </span>And not eliminate them from the
table.<span> </span>Having the reference right there
is still useful, regardless of whether we have an appendix for more
information.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – Perhaps some of the RFC 5280 references could be
dropped or condensed.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – Part of my reasoning for thinking of the appendix is that
CAs should already be fully using the ASN module.<span> </span>Using the ASN1 module should resolve issues
like this.<span> </span>They should be using the ASN1
generator.<span> </span>So we really need to focus on
the contents and the validation, that is what was behind my thinking on this. <span> </span><span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wayne asked on chat:<span>
</span>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?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – I can see that value. I still think specification
references should be in an appendix.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – One idea for an organizing principle is that all of
the “what” should be in the tables.<span> </span>Informatives
and “whys?” are non-normative and belong in the appendix.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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. <span> </span>Later we can replace this
directory string with explicitly printable string or UTF8 string. <span> </span>We could be more restrictive than the ASN1
types.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – That’s a reasonable argument for the distinguished
name, but not as important for TBS certificate. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – This does not need to be a guide for how to become a
CA because the level of sophistication goes way beyond this.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ryan – I disagree.<span>
</span>This should be a profile.<span> </span>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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span>
</span>If we are going that direction, then the tables need to be more free-standing. I don’t want the information to be lost.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Wendy said on chat: I would like it to be crystal clear if a
"limit" is from a standard vs just imposed by CABForum.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Trev - agrees with Wendy. <span> </span>We should be clear about who the audience is
for this table.<span> </span>This should be clear for
CAs and clear for customers when they disagree. <span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – External specifications will make people less upset.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Trev – What about having examples? Maybe on the website for
how this thing should look.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – That’s good, but then people will argue that something
can’t be done because it doesn’t follow the example.<span> </span>I agree with both sides of the argument.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Corey – Appendix C of RFC 5280 has examples.<span> </span>I’m not sure that we want to get into this
level of specificity, but we could include dumps of certificates.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Tim – We could reference lines from that appendix rather
than creating our own.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Ben asked on chat:<span>
</span>Why can't the table be landscape-formatted rather than portrait style?<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">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.<span></span></p>
<p class="MsoNormal" style="margin:0in 0in 8pt;line-height:107%;font-size:11pt;font-family:"Calibri",sans-serif">Meeting adjourned.<span></span></p>
</div></div>