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

[Ryan Sleevi]

On Thu, Aug 27, 2020 at 1:26 PM Robin Alden via Validation <
validation at cabforum.org> wrote:

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

s/CRL/CPS/ (on the most minor of nits)


> 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
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200827/ec9f7df6/attachment.html>