[cabf_validation] Minutes of the Validation Subcommittee call on 2020-09-24

[Clint Wilson]

Minutes of the Validation Subcommittee call on 2020-09-24
Antitrust statement was read.

Attendees: Aneta Wojtczak, Ben Wilson, Clint Wilson, Daniela Hood, Douglas Beattie, Enrico Entschew, Janet Hines, Joanna Fox, Johnny Reading, Li-Chun Chen, Niko Carpenter, Rebecca Kelley, Shelley Brewer, Tim Hollebeek, Trevoli Ponds-White, Wayne Thayer

Summary: This week’s discussion continued focus on defining certificate profiles in support of a future ballot to reorganize and clarify the associated sections of the BRs/EVGs. Today we touched on streetAddress, country, organizationName, and organizationUnitName. 

Agenda: Continuing work on certificate profile attribute spreadsheets

Minutes:
Douglas Beattie: Li-Chun Chen sent an email; intent is to clarify and specify here so we can reorganize the associated sections. May not be able to incorporate them yet.
Tim Hollebeek: We can capture them so they’re not forgotten
Douglas Beattie: Absolutely; we can include a link from pipermail right in the comments to reference his comments
Li-Chun: On the subscriber TLS table, for OV/IV SSL for the state, they are required but no comments exist currently on the document. I’d suggest to keep it required when orgName, givenName, or surName are present and locality is absent.
Tim Hollebeek: So picking up on the TLS Distinguished Names tab, down to streetAddress
Wayne Thayer: Having some debates about length requirement for streetAddress, and whether multiple are allowed.
Tim Hollebeek: That could be a concern for multiple fields that we haven’t addressed. Are there examples?
Douglas Beattie: Ryan brought up one for country.
Tim Hollebeek: There are cases where there are two relevant country codes, but I wouldn’t have thought it appropriate to put both in. Could we make a blanket statement that unless otherwise stated, each field is only allowed once.
Wayne Thayer: After we’ve done an assessment, yes.
Tim Hollebeek: streetAddress mentions RFC5280, but another question I had tangentially here is how far are we going to go in chasing 5280 and all its normative references as far as defining certificate profile requirements.
Clint Wilson: Given the stability of the RFCs, it seems like a worthwhile effort
Tim Hollebeek: Yeah and removing the ambiguity of finding a requirement that’s 3 levels deep in RFCs
Wayne Thayer: I definitely support pulling in the length, but beyond that depends on how much effort is required
Douglas Beattie: The encoding is also pretty important to pull in
Tim Hollebeek: We’ll think about that one. Moving on to postalCode; anything useful here? Moving on to organizationName. Haven’t heard too much on this, except we should make sure to put length limits.
Douglas Beattie: organizationName references the Subscriber TLS tab, but that references back to TLS Distinguished Names tab.
Tim Hollebeek: It’s not quite a circular reference, but it’s close.
Douglas Beattie: Required/optional is on the Subscriber TLS tab for different types of certificates, and then the contents are more or less in column C. Add in the required/optional summary to column F on TLS Distinguished Names tab.
Wayne Thayer: Is this TLS Distinguished Names for only subscriber certificates? Because CAs are a whole different world
Douglas Beattie: I think it’s just subscriber certificates because the Subordinate CA tab includes the necessary detail.
Tim Hollebeek: There are some references to the Distinguished Names tab on the Root CA/Subordinate CA; should we delete that?
Douglas Beattie: No, but we could mark it as something to come back to.
Tim Hollebeek: Done with organizationName now?
Douglas Beattie: I think the Validation column needs to included all the info from column C.
Tim Hollebeek: What’s the difference between column C and column G
Douglas Beattie: We’re getting rid of column C; it combines Validation and “Required/Optional”
Wayne Thayer: And I think the idea is to make it more readable by making the outbreak more readable by converting it to more bulletized lists, like what we have with stateOrProvinceName.
Tim Hollebeek: Not sure there’s much more to say about organizationUniteName from a certificate profile point of view.
Wayne Thayer: Agree, let’s not focus on whether it’s allowed and instead focus on how it would appear.
Douglas Beattie: If you read the latter part of the current text around OUs literally, it seems to restrict this a great deal
Tim Hollebeek: There’s a bug here, and the phrasing does make it difficult to parse out which dependent clause is dependent on what. I’ll write in the Validation column a version that better captures the original intent.
Wayne Thayer: So does that mean there are no requirements for how to validate an OU for a DV cert?
Tim Hollebeek: I think so
Douglas Beattie: The paragraph has two parts, how to validate it, and when it needs to be validated. We need to copy part of it out into the Required/Optional.
Wayne Thayer: It’s always optional
Douglas Beattie: Could be prohibited for DV though
Tim Hollebeek: I think the BRs are silent on that. I’ll try to break it out like Wayne said.
Douglas Beattie: I think Optional for OV/EV/IV, and prohibited for DV
Wayne Thayer: Is that the current interpretation of the debate, that it’s prohibited in DV?
Douglas Beattie: We could then simplify the Validation section, since we can remove the “when it needs to be validated” part since it now always needs to be, if it’s included.
Wayne Thayer: This leaves us still with a very limited validation requirement, so having it tie back to 3.2 requirements would help.
Tim Hollebeek: That would definitely be an improvement, but I think the current requirement is that if the OU doesn’t contain one of the identified/listed contents, then there are no validation requirements.
Trevoli Ponds-White: So this might be silly, but what is a “name” in the context of the OU validation requirements as currently written?
Joanna Fox: What about if we just said “if the OU contains any text referring to a specific person....”?
Tim Hollebeek: That’d be an improvement, and we’re supportive of that.
Trevoli Ponds-White: The whole challenge is in figuring out whether the text refers to a natural person or entity. Any text could be one of those things, so I’m not sure if we’re being helped by attempting to constrain it. Right now, you’re basically figuring out an exhaustive list of all words.
Wayne Thayer: I don’t disagree with that, but I don’t think that was the original intent. I think it was to not allow Acme, Inc. to include “Campbells soup” and pretend it was a certificate that had something to do with Campbells soup. It’s not supposed to mislead about the relation between different named parts of the subjectDN.
Tim Hollebeek: I think that was the intent, and it’s hard to argue the current wording meets the intent. Trademark would need to be used in a way that’s consistent with trademark scope.
Douglas Beattie: I don’t think 3.2 includes a process for validating a trademark.
Tim Hollebeek: It doesn’t. Only in very constrained cases can 3.2 be used to validate things. 
Shelley Brewer: Trademark stuff would be 3.1.6
Tim Hollebeek: It’s possible to validate trademarks without opining on whether they were issued correctly
Shelley Brewer: So that kind of process would need to be added into the BRs
Tim Hollebeek: Yes, the challenge is in coming up with language that represents the intent and that is a challenge. If we’re going to leave trademark/tradename in there, we have to identify how to validate those. There’s no consideration for fair use here.
Niko Carpenter: If someone is making a product, are they allowed to put that in the OU of certs that product issues, even if unassociated to the org using the product?
Tim Hollebeek: Seems like there’s more interest in cleaning this up than I expected, so we can pick that up next call.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200924/ef8e971c/attachment.p7s>