[cabf_validation] Minutes of the Validation Subcommittee call on 2020-10-08

[Clint Wilson]

Minutes of the CA/B Forum ServerCert WG Validation Subcommittee meeting - Thursday, October 8, 2020
Antitrust statement was read.

Attendees: Amanda Mendieta, Ben Wilson, Bruce Morton, Clint Wilson, Daniela Hood, Johnny Reading, Li-Chun Chen, Rebecca Kelley, Rich Smith, Shelley Brewer, Thomas Zermeno, Trevoli Ponds-White, Wendy Brown

Today we continued to review certificate profiles, finishing OU, CN, givenName, surName, and "any other Subject Attributes".
Next meeting we’ll look at how to move the certificate profiling work that’s been done forward, and at what new work the subcommittee might look to take on next.

OUs
	• Wayne Thayer: Couple things happening with OU. First, lots of ambiguity in current validation requirement. Second, questions of whether we even want to continue allowing it. There’s some ambiguity of whether it’s allowed in DV, but consensus seems to be it’s not; I’m not sure we want to continue to allow it in EV/OV either. Unsure of whether we should deprecate altogether.
	• Ben Wilson: Some CAs may be hesitant to talk about it since there may be a sense that there’s opposition to it.
	• Thomas Zermeno: It does seem like the winds are blowing a certain direction.
	• Wayne Thayer: Should we define better validation requirements, or punt?
	• Ben Wilson: I’d say punt on it. It’s a bit messy; one side is that no one looks at it except large enterprise PKIs that need a way to track certificates better. Maybe one department deals with IBM or Microsoft or whomever products, so including information about that might be a way of tracking where the cert’s located in the infra, but that also includes trademarked information.
	• Wendy Brown: If the org is something really large, like a government, the OU might be really relevant since you’re issuing to maybe some specific portion of the government, like the Navy or NASA.
	• Wayne Thayer: That’s a fairly strong argument, but doesn’t change much about the counter-argument. Probably the best argument for why we should allow it.
	• Trevoli Ponds-White: Some are probably hesitant because there’s not very many of us, to break other CAs by supporting disallowing it. It should be something we discuss further on list to get more views.
	• Thomas Zermeno: For browser use, not sure, but there certainly are extensive uses of the OU for some companies, like energy entities.
	• Wayne Thayer: Coming up with validation will be a very difficult task, in a way that’s clear and achieves the goal.
	• Trevoli Ponds-White: In the wild, it does seem like it can’t have much validation, so much as syntax requirements. Validating some company’s personal labeling system is challenging.
	• Wayne Thayer: The one we want to aim for is sort of a negative requirement. Easy to describe, but not to enforce; you can use it, but you can’t have it be misleading.
	• Ben Wilson: Speaking as an individual, I think that’s fine and a good direction.
	• Trevoli Ponds-White: Are there use-cases where people are using this to convey information to users outside their organization? I’m not sure it’s warranted to really worry about it confusing people in an internet browser. Is the concern about this field correct in being about consumers on the internet? They don’t look at this field.
	• Wayne Thayer: Practically speaking, that’s a very valid point. At the same time, do we really want to say “you can put whatever you want in this field” and then have CAs put things that are clearly misleading in here?
	• Thomas Zermeno: Is there an example of something that’s clearly misleading?
	• Wayne Thayer: Making a product, but putting someone else’s trademark in there; that would be pretty misleading.
	• Rich Smith: Defining validation requirements is nearly impossible. We’ve also got wording that’s impossible to enforce since it can be interpreted by whomever reads it to mean whatever they want. It’s nebulous, undefined, and nearly undefinable. I don’t know the solution, which is why I posted a ballot that mostly identified the problems in hopes of prompting the group to fill in a solution, which hasn’t happened.
	• Wayne Thayer: Which is kind of a case for banning OU. The requirements as they stand are difficult to interpret, so if we’re not willing to say this field is a free-for-all and we can’t fix the current requirements, then it seems we need to ban it.
	• Trevoli Ponds-White: Agree; as a different example, if you think about moderating Facebook and Twitter, they have armies doing simply establishing whether something’s fake or misleading. Doing the same for certificates, and trying to determine if something’s misleading especially when you add in cultural contexts, we’d need an army of moderators.
	• Wayne Thayer: Either we allow CAs to use their own judgement or we ban it?
	• Daniela Hood: Argument to keep it is that some organizations use OU to organize their certs. They wouldn’t have any other way to organize their certs other than using that field?
	• Trevoli Ponds-White: Not directly within the certificate. Multiple entities that don’t operate together, but have to share a primary/base domain.
	• Ben Wilson: With Wendy’s argument, it’s the O that’s already taken.
	• Daniela Hood: To your point, Trev, no one goes into a certificate to look at that and it doesn’t seem like a big deal.
	• Trevoli Ponds-White: If we think internet users are at risk of looking at this, then we need to do something about it, but this is a different use-case it seems.
	• Ben Wilson: It’s an easy thing to put it in, it’s low-hanging fruit to throw in something for someone generating a cert.
	• Rich Smith: We’ve got to fix the wording where we’ve got organization and surname and givenname, since that wording implies (not that it’s the accepted requirement) that all three be present. If we leave the rest of it, it’s been there this long, and the problem is mostly just that it’s basically meaningless. I hate the other wording that’s there, but don’t really see what we can replace it with.
	• Wayne Thayer: It feels like we’ve talked through this as much as we’re gonna get and it needs to be resolved by having a ballot out there and have the debate. Might be worthwhile to push Rich’s ballot forward so we can have that discussion.
	• Rich Smith: I don’t think my ballot has legs without adding verification requirements, so maybe the way to go is to scrap my ballot since I’m not sure what to put in as verification requirements, and instead post a ballot to remove OU altogether.
	• Wayne Thayer: I think a ballot that forbids OU would be more constructive, so if anyone wants to take that on, that would be valuable.
	• Rich Smith: I’ll take that on, draft something up and throw it out there. Getting it into discussion period should be fairly easy as there are supporters.
	• Wayne Thayer: Any other comments on OU?

CommonName
	• Wayne Thayer: The commonName is populated differently in Root and CA certificates, so will be broken out across the different profiles. Is there anything more we need to do with CN for subscriber certificates? For Root and Intermediate and Subscriber certificates we have it defined already to some extent, so it looks pretty good.
	• Trevoli Ponds-White: Don’t we say it’s discouraged? We should decide if it’s discouraged or optional; discouraged isn’t very helpful.
	• Ben Wilson: The whole thing about it being deprecated is a problem; we have a solution that works (CN has to be in the SAN).
	• Wayne Thayer: It feels like we’re saying we want to prohibit it in the future.
	• Trevoli Ponds-White: Should be either “optional and must match X”, or “will be deprecated when X occurs”
	• Clint Wilson: Seems like we need a ballot if we actually want to move forward with getting it deprecated/removed, so keep it optional until or unless that happens.
	• Wayne Thayer: Yeah and there are no barriers to someone putting that ballot forward. Anything else on commonName?

GivenName
	• Wayne Thayer: Currently the BRs basically just say the cert must contain the IV policy OID if this is present
	• Thomas Zermeno: Is there a reciprical requirement that anything with that policy OID must have this field?
	• Clint Wilson: I don’t believe so since there’s a provision that allows using the O field for a person. 

SurName
	• Wayne Thayer: Same applies to surName

Other subject attributes
	• Wayne Thayer: The comment here is do we want to allow organization identifier, which is currently permitted by the EVGs?
	• Ben Wilson: I think we do; this is related to eIDAS, right?
	• Wayne Thayer: The EU in at least one of their profiles does require an organizationIdentifier, but that’s an EV profile I think for a banking requirement. I don’t recall anyone from ETSI saying they need organizationIdentifier in an OV certificate.
	• Bruce Morton: I think it’s the PSD2 certificates
	• Ben Wilson: I did notice there’s one with CAs, but we’re looking at leaf profiles right now. We can come back to it when we get to CAs.
	• Bruce Morton: I think you’re right, that there’s an eIDAS one where you put this field in a CA, but I don’t think that’s for TLS.
	• Wayne Thayer: So do we want to pull in the requirements from EV for regular OV certificate requirements?
	• Bruce Morton: It’d make it cleaner to have one place
	• Wayne Thayer: In the prior column, it does say that other attributes can be included so long as they’re verified. So there’s no prohibition of including organizationIdentifier so long as it’s verified.
	• Clint Wilson: I think the argument that comes to mind is that if we want to align the verification requirements for organizationIdentifier to ensure they’re consistent between OV and EV, then we’d want to bring them in here since otherwise OV could be verified some other way based on the “other attributes” verification requirements.
	• Wayne Thayer: EVGs does have pretty substantial, specific semantic requirement, which arguably is good if we want it to be machine readable. Should we copy?
	• Rich Smith: If we want to allow for OV, we should move it into the BRs and then update the EVGs to reference that, then update in the BRs if we want to change the requirements in the future.
	• Wayne Thayer: Ryan makes a comment of whether the more strict EV validation is underpinning the validation of the organizationIdentifier, so can we move it into the BRs.
	• Rich Smith: The main difference I see is the EVGs has a very strict requirement to verify the legal existence of the entity, where that requirement doesn’t exist in OV.
	• Wayne Thayer: Anything else on organizationIdentifier? 
	• Wayne Thayer: Is there a desire to ban other subject attributes? 
	• Clint Wilson: I think we want to have well-specified processes for verifying information that’s included, so it does seem worthwhile for that to happen before new fields start getting included.
	• Wayne Thayer: So there’s still a MAY here for now, but maybe in the future we would look at changing this to forbid
	• Bruce Morton: Would we want to go through a similar process to what happened with domain validation, where we defined some methods and then before forbidding requested everyone to describe any other processes in use?
	• Wayne Thayer: Yeah that’s a good idea, we should ask CAs what other fields they’re using and/or do a scan to see what other certificates we find.

Concluding remarks
	• Wayne Thayer: It looks like we’re done with this tab, and we’re just about out of time for today. We’ll call it, and next time we’ll discuss what we want to do next with this spreadsheet to move it forward, and what work the subcommittee wants to take up next.
-------------- 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/20201013/e9fd9467/attachment.p7s>