<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 27, 2020 at 1:26 PM Robin Alden via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Minutes of the Validation subcommittee call on 2020 08 27<br>
<br>
Antitrust statement was read.<br>
<br>
Present:<br>
Tim Hollebeek (leading)<br>
Wayne Thayer<br>
Amanda Mendieta<br>
Aneta Wiecheck<br>
Ben Wilson<br>
Bruce Morton<br>
Clint Wilson<br>
Daniella Hood<br>
Janet Hines<br>
Jonny Reading<br>
Kirk Hall<br>
Li-Chun Chen<br>
Niko Carpenter<br>
Rebecca Kelley<br>
Ryan Sleevi<br>
Robin Alden (minutes)<br>
Shelley brewer<br>
Trevoli Ponds-White<br>
<br>
Continuing to discuss subscriber certificate profiles..<br>
<br>
We picked up by finishing off keyUsage 7.1.2.3(e)<br>
<br>
extKeyUsage 7.1.2.3(f)<br>
Ryan pointed out that 7.1.2.4 applies to all certificates and so must be considered here.<br>
<br>
7.1.2.3 (g) is new in the BRs - SC31 imported this from Mozilla's policy.<br>
7.1.2.3 (g) authorityKeyIdentifier (required)<br>
This extension MUST be present and MUST NOT be marked critical. It MUST contain a<br>
keyIdentifier field and it MUST NOT contain a authorityCertIssuer or<br>
authorityCertSerialNumber field.<br>
<br>
(added this language to the sheet)<br>
<br>
we did certificatePolicy, keyUsage and nameconstraints inline.<br>
EKU is the only place that we have the extension.<br>
certificatePolicy may be a little wierd<br>
Ryan: Just making sure we have the encoding vs the validation specified.<br>
<br>
We Filled in column Q (Source of Requirement) for some elements on the subordinate CA and the subscriber TLS tabs.<br>
<br>
Ryan: keyUsage: digitalSignature is marked as required, similar with keyEncipherment - but that's not correct because it depends on the type of key and the ciphersuites it will be used with.<br>
Should we split to keyUsage (RSA) & keyUsage (ECC), or keyusage (generic) and indicate separately for RSA & ECC.<br>
Tim: I prefer the latter.<br>
<br>
signatureAlgorithms missed so far<br>
notAfter & notBefore missed so far.<br>
<br>
Ryan: On Subscriber TLS, policyQualifierID, RFC5280 has these as SHOULD NOT, which would also discourage the HTTP URL for the CRL.<br></blockquote><div><br></div><div>s/CRL/CPS/ (on the most minor of nits)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A number of CAs put cpsURI in. EU CAs rely on this because they put their qualifiedstatements here. Some CAs have started omitting it.<br>
Ben: In favour of not putting anying.<br>
Bruce: We've always put it in.<br>
Ryan: I'm in favor of cleaning this up in the future. Added a note to discuss this in future.<br>
<br>
Ben: keyUsage - theres only 8, we should discuss.. is keyAgreement required for ECC.<br>
Tim: Not required, but the question is whether it is allowed.<br>
Ben: Getting back to the idea of splitting RSA and EC, we should be more explicit.<br>
Tim: I agree only 8, but it's a bit of a task to explicitly list and analyze all keyUsages.<br>
Added a note that this task needs to be done. Maybe we need to use Trello to track and prioritize the remaining work.<br>
<br>
We have yet to do:<br>
EV GLs<br>
algorithms and keyUsages<br>
Sources for all requirements<br>
fields that are in 5280 but not the BRs.<br>
CRL profiles(?) - lots in 5280. (Wayne - not highest priority)<br>
Other tabs in the sheet<br>
- TLS DNs<br>
<br>
TLS distinguishedNames<br>
countryName<br>
(we have columns C and G, both titled 'Validation')<br>
<br>
Wayne: We want to populate the validation profiles in these requirements. E.g. SAN field put in all the validation requirements.<br>
Tim: My take was that this was more profile based. field length, allowed/required/prohibited, etc.<br>
Ben: Let's change the title of column C to content validation (done).<br>
<br>
Tim: stateOrProvinceName, I would be amenable to any fix that is auditable. Currently it doesn't say much other than this is where you put the state or province.<br>
What kinds of subdivision meet that definiteion - it doesn't say.<br>
Robin: There is the process in flight of CAs listing what they do. We can analyze the results of that.<br>
Tim: Can we lock this down to 3166-2? Objection: some places don't have a 3166-2 subdivision.<br>
Robin: Some language variants are missing (China?) 3166 is anglo-centric. It has some alternate language versions, but not a wide range.<br>
Bruce: Subscriber says he's at some given address, but I can't match it to 3166-2.<br>
Tim: if its a valid mailing address like 'AP' (US Army, Pacific) should we be able to represent it in a certificate? Asked on the list but no opinions forthcoming.<br>
Robin: Agree, but what about where the registry or source of truth says the customer is. If the registry doesn't use the same as ISO 3166-2 then we cannot match.<br>
Tim: Depends how strict we get with localityNames<br>
Bruce: Even localityName is a problem when cities merge. Locality doesn't change within the city, but addresses can keep the old city names.<br>
Tim: always wondered about the address I am at - if you believe the USPS I am in Pittsburgh, but I am not actually in the city of Pittsburgh<br>
Shelley: When I was in England, my address did not exist to the USPS, but was very real to the Royal Mail.<br>
Rich: Even companies house (in the UK), there are things in there under 'state' (UK county) that don't match ISO.<br>
ISO is fed by one branch of a particular government. Even other departments in the government don't necessarily agree with the values chosen!<br>
Real world is messy.<br>
Tim: What list or principles can we get to?<br>
good point on 'what do the registration agencies say.' We probably should agree with the registration agency.<br>
When we examine the CA disclosures I think we will find some registries are a mess.<br>
Robin: Some countries will be, yes. This is an area where 'common sense' fails us because either we are in a country where there is a realy regular system (like the US) whereas some other countries have very irregular systems.<br>
Shelly: does ISO deal with HK and Palestine?<br>
Tim: COuntries are better stated that stateOrProvince.<br>
Robin: ISO has HK twice, both HK HK and HK CN.<br>
Tim: That's why 3166-2 is annoying, because it is an attempt at solving an unsolvable problem.<br>
<br>
moving on..<br>
<br>
localityName has all of the same issue (punting for now)<br>
<br>
streetAddress<br>
Shelley: That's why I was unfindable in the UK. a 'Street' address had been created within a Victorian factory building that had been split into flats.<br>
<br>
postalCode - implication is that it is copied from the postal address.<br>
<br>
organizationName: RFC5280 length is a problem. Interop issues..<br>
<br>
Tim: organizationalUnitName: Either solve the existing language or move away from them.<br>
Robin: our view is (surprisingly to us) that we probably get rid<br>
Tim: Agreed, but if we move away from them its important we do so in an orderly manner<br>
<br>
Rich: Sometimes the OU is being used to put a legit organizationalIdentifier in. Let's get rid of the OU but allow the organizationIdentifier field in OV certs. (it is already in EV).<br>
Tim: Would you have a requirement on the format or value?<br>
Rich: Yes, I think so. At that point LEI has now been adopted as an ISO standard and it could be adopted.<br>
ICDs (OID 1.3. arc(?))<br>
Stick with what is defined in EV. Maybe extend it with others if there is an appetite to do so and they make sense.<br>
Problem has been that it is a free form field with no verification requirements (other than 'not misleading'!)<br>
Tim: That's why I think the 'number' restriction is useful, because it's harder to be misleading with a numeric field.<br>
Rich: That's why I think we introduce organizationalIdentifier for both OV and EV.<br>
Tim: Or another field if there are objections to organizationalIdentifier for OV.<br>
Rich: Sure, not wedded to organizationalIdentifier in particular, but it does have existing semantics.<br>
Tim: organizationalIdentifier identifies the subject, but not clear that the internal identifiers used by subjects are subject information.<br>
Rich: We see an ICD used in a French context. ICD is Siren/Siret, which fits fine in OU. (org number or org number + branch identifier).<br>
Tim: There are use cases where the OU is being correctly used.<br>
Rich: Too much historical cruft in OU fields we should start again.<br>
Tim: I think you're right. When I started in this field and asked where we could put an 'X' field - the answer was always 'In the OU field!'<br>
<br>
Tim: Next time we will pick up with commonName<br>
Tim: Meet again in two weeks when I think I might not be here.<br>
<br>
Robin Alden<br>
Sectigo<br>
_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</blockquote></div></div>