[cabf_validation] Minutes of the Validation subcommittee call on 2020 08 27

[Robin Alden]

Minutes of the Validation subcommittee call on 2020 08 27

Antitrust statement was read.

Present:
Tim Hollebeek (leading)
Wayne Thayer
Amanda Mendieta
Aneta Wiecheck
Ben Wilson
Bruce Morton
Clint Wilson
Daniella Hood
Janet Hines
Jonny Reading
Kirk Hall
Li-Chun Chen
Niko Carpenter
Rebecca Kelley
Ryan Sleevi
Robin Alden (minutes)
Shelley brewer
Trevoli Ponds-White

Continuing to discuss subscriber certificate profiles..

We picked up by finishing off keyUsage 7.1.2.3(e)

extKeyUsage 7.1.2.3(f)
Ryan pointed out that 7.1.2.4 applies to all certificates and so must be considered here.

7.1.2.3 (g) is new in the BRs - SC31 imported this from Mozilla's policy.
7.1.2.3 (g) authorityKeyIdentifier (required)
This extension MUST be present and MUST NOT be marked critical. It MUST contain a
keyIdentifier field and it MUST NOT contain a authorityCertIssuer or
authorityCertSerialNumber field.

(added this language to the sheet)

we did certificatePolicy, keyUsage and nameconstraints inline.
EKU is the only place that we have the extension.
certificatePolicy may be a little wierd
Ryan: Just making sure we have the encoding vs the validation specified.

We Filled in column Q (Source of Requirement) for some elements on the subordinate CA and the subscriber TLS tabs.

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.
Should we split to keyUsage (RSA) & keyUsage (ECC), or keyusage (generic) and indicate separately for RSA & ECC.
Tim: I prefer the latter.

signatureAlgorithms missed so far
notAfter & notBefore missed so far.

Ryan: On Subscriber TLS, policyQualifierID, RFC5280 has these as SHOULD NOT, which would also discourage the HTTP URL for the CRL.
A number of CAs put cpsURI in.  EU CAs rely on this because they put their qualifiedstatements here.  Some CAs have started omitting it.
Ben: In favour of not putting anying.
Bruce: We've always put it in.
Ryan: I'm in favor of cleaning this up in the future.  Added a note to discuss this in future.

Ben: keyUsage - theres only 8, we should discuss..  is keyAgreement required for ECC.
Tim: Not required, but the question is whether it is allowed.
Ben: Getting back to the idea of splitting RSA and EC, we should be more explicit.
Tim: I agree only 8, but it's a bit of a task to explicitly list and analyze all keyUsages.
Added a note that this task needs to be done.  Maybe we need to use Trello to track and prioritize the remaining work.

We have yet to do:
        EV GLs
        algorithms and keyUsages
        Sources for all requirements
        fields that are in 5280 but not the BRs.
        CRL profiles(?) - lots in 5280.  (Wayne - not highest priority)
        Other tabs in the sheet
        - TLS DNs

TLS distinguishedNames
countryName
(we have columns C and G, both titled 'Validation')

Wayne: We want to populate the validation profiles in these requirements. E.g. SAN field put in all the validation requirements.
Tim: My take was that this was more profile based.  field length, allowed/required/prohibited, etc.
Ben: Let's change the title of column C to content validation (done).

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.
What kinds of subdivision meet that definiteion - it doesn't say.
Robin: There is the process in flight of CAs listing what they do.  We can analyze the results of that.
Tim: Can we lock this down to 3166-2?  Objection: some places don't have a 3166-2 subdivision.
Robin: Some language variants are missing (China?)  3166 is anglo-centric.  It has some alternate language versions, but not a wide range.
Bruce: Subscriber says he's at some given address, but I can't match it to 3166-2.
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.
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.
Tim: Depends how strict we get with localityNames
Bruce: Even localityName is a problem when cities merge.  Locality doesn't change within the city, but addresses can keep the old city names.
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
Shelley: When I was in England, my address did not exist to the USPS, but was very real to the Royal Mail.
Rich: Even companies house (in the UK), there are things in there under 'state' (UK county) that don't match ISO.
ISO is fed by one branch of a particular government.  Even other departments in the government don't necessarily agree with the values chosen!
Real world is messy.
Tim: What list or principles can we get to?
good point on 'what do the registration agencies say.'  We probably should agree with the registration agency.
When we examine the CA disclosures I think we will find some registries are a mess.
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.
Shelly: does ISO deal with HK and Palestine?
Tim: COuntries are better stated that stateOrProvince.
Robin: ISO has HK twice, both HK HK and HK CN.
Tim: That's why 3166-2 is annoying, because it is an attempt at solving an unsolvable problem.

moving on..

localityName has all of the same issue (punting for now)

streetAddress
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.

postalCode - implication is that it is copied from the postal address.

organizationName: RFC5280 length is a problem.  Interop issues..

Tim: organizationalUnitName: Either solve the existing language or move away from them.
Robin: our view is (surprisingly to us) that we probably get rid
Tim: Agreed, but if we move away from them its important we do so in an orderly manner

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).
Tim: Would you have a requirement on the format or value?
Rich: Yes, I think so. At that point LEI has now been adopted as an ISO standard and it could be adopted.
ICDs (OID 1.3. arc(?))
Stick with what is defined in EV.  Maybe extend it with others if there is an appetite to do so and they make sense.
Problem has been that it is a free form field with no verification requirements (other than 'not misleading'!)
Tim: That's why I think the 'number' restriction is useful, because it's harder to be misleading with a numeric field.
Rich: That's why I think we introduce organizationalIdentifier for both OV and EV.
Tim: Or another field if there are objections to organizationalIdentifier for OV.
Rich: Sure, not wedded to organizationalIdentifier in particular, but it does have existing semantics.
Tim: organizationalIdentifier identifies the subject, but not clear that the internal identifiers used by subjects are subject information.
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).
Tim: There are use cases where the OU is being correctly used.
Rich: Too much historical cruft in OU fields we should start again.
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!'

Tim: Next time we will pick up with commonName
Tim: Meet again in two weeks when I think I might not be here.

Robin Alden
Sectigo