[cabf_validation] Minutes of the Validation Subcommittee call on

陳立群 realsky at cht.com.tw
Thu Oct 8 02:26:48 MST 2020


Would Tim mind adding a comment " Required when organizationName is present and localityName is absent "  in RAW 24 and Column P of Subscriber TLS tab in https://docs.google.com/spreadsheets/d/1G-ADocQbNJE7XoRlbTfQtub6SF7xq34SBoEGu-wBh_k/edit#gid=1166390362 
for Subject (OV)?

I remember Tim had edited in last Validation Subcommittee Meeting two weeks ago for Subject (OV). But it seems that the comment is disappeared now.

Would Tim mind adding a comment " Required when givenName and surName are present and locality is absent "  in RAW 36 and Column P of Subscriber TLS tab in https://docs.google.com/spreadsheets/d/1G-ADocQbNJE7XoRlbTfQtub6SF7xq34SBoEGu-wBh_k/edit#gid=1166390362 
for Subject (IV)? Thanks. 

 

          Li-Chun 

-----Original Message-----	
From: Validation <validation-bounces at cabforum.org> On Behalf Of Clint Wilson via Validation
Sent: Friday, September 25, 2020 4:08 AM
To: validation at cabforum.org
Subject: [外部郵件] [cabf_validation] Minutes of the Validation Subcommittee call on 2020-09-24

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.


本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.


More information about the Validation mailing list