[cabf_validation] CABF: Minutes from the Validation Subcommittee meeting at 2020-12-03

[Dimitris Zacharopoulos (HARICA)]

- Antitrust statement

The Antitrust Statement was read.


- Attendence


Amanda Mendieta (Apple), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson 
(Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnel 
(Digicert), Daniela Hood (GoDaddy), Dimitris Zacharopoulos (HARICA), 
Doug Beattie (GlobalSign), Janet Hines (SecureTrust), Johnny Reading 
(GoDaddy), Michelle Coon (OATI), Niko Carpenter (SecureTrust), Paul van 
Brouwershaven (Entrust), Rebecca Kelley (Apple), Rich Smith (Sectigo), 
Ryan Sleevi (Google), Shelley Brewer (Digicert), Stephen Davidson 
(Digicert), Tim Hollebeek (Digicert), Wayne Thayer (Mozilla).


- Agenda


Two items were added to the agenda:

1. Wildcard and ADN validation

2. Extensions based on BRs 7.1.2.4


- Wildcard and ADN validation


Ryan sent a message on the list about concerns raised in meeting #43 
around Domain Validation methods related to agreed-upon change to a website.


These methods practically demonstrate control for a particular Domain 
Name, the Domain Name of the website and not for the Domain Namespace.


Change agreed upon change to web sites should not validate ADNs and 
wildcard certificates.


DNS are ok for ADNs and wildcards.


Ryan would like to propose that it becomes effective immediately, around 
February 2021. If CAs anticipate problems with that timeline, they 
should send feedback with some useful data, since this is one of the 
automatable methods that doesn't really need human interaction. He is 
looking for initial reactions, challenges anticipated, any useful 
feedback would help during the preparation of the ballot.


Doug mentioned that Globalsign uses this method for Enterprise accounts 
so they can validate their Domain and then issue Certificates to 
sub-domains. It can be typically automated but not all systems on these 
Enterprises can use ACME. This would be something GS would like to push 
down the road, more than February 2021 so they can let their customers 
know this is coming. Doug also mentioned that it is important to know 
how we will handle validation re-use for sub-domains that were validated 
using these methods after this change is made. Will they immediately 
expire or have a transition?


Ryan said that this is where the email touches on, to trigger discussion 
on such challenges. For example, he expects not resolvable subdomain 
validations to be a challenge using these methods for these subdomain 
validations.


Ryan describes in his email what sort of data would be useful for CAs to 
collect and present. He is not opposed to pushing the date down the road 
but we should do this based on actual data. He proposed CAs to collect 
statistics and useful data for a concrete discussion. This would help 
set a better timeframe. CAs could also indicate their timeline to get 
this data, if they decide to do so. He agrees that examination of data 
takes time but CAs can mention how much time they need to collect this 
data. We certainly need to understand the impact before going forward.


Dimitris asked Ryan that in his email, the "www" label was mentioned 
separately when looking for statistics. It appeared as a "special case" 
and was curious if there were any plans for an exception.


Ryan replied that there was no intention of having an exception or 
"special treatment" for the "www" label. If the "www" is in the same 
server as the bare domain, it should be easy for the CA to use the same 
validation challenge for both domains. Two connections would be required 
to the two Domain Names but they could use one random value. For 
example, today the CA can validate example.com connect to example.com 
and get authorization to issue for www.example.com. After this update, 
the CA would need to connect to example.com and to www.example.com to 
get the same random value to issue for www.example.com and example.com.


Tim mentioned that the "www" label was used as a special case in the 
past because of how browsers treated this label, adding it automatically 
in some cases. He described a workaround for users that typed bare 
domain names in the address bar and browsers would historically do 
things like "let's see what happens if I add www to this". Ryan said 
this behavior has changed for the better and does not apply for almost a 
decade. Now you would need to do [CONTROL - ENTER] to "magically" add 
the www, and no one really knows about this behavior.


Ryan suggested to use the mailing list for first reactions, possible 
gotchas and in case CAs need time to gather data, they should just 
mention how much time they would need, it would be very useful.


Tim said that there should be some convergence and deadline on data 
feedback so this process doesn't go on forever.


Wayne added that there is a combination of factors (notifying customers, 
validation systems need to be modified, what has to happen with 
previously validated data) that make this proposed change clearly not 
happening overnight. He wasn't sure why the initial proposal was from 
the perspective of "let's make this effective immediately" and request 
data to push this forward, instead of taking the historically and 
typical approach proposing it to be effective 6 months after the ballot 
is effective. The 6 month effective time seems more realistic with this 
ballot and would help us move more quickly than trying to get data from 
people.


Ryan said that we set the standard to 3 months, not 6. The collection of 
data can help us tweak the effective dates. The goal is not to rush this 
through in February but get data to support informed decisions. We have 
a number of variables that need to be sorted out.


Tim echoed Wayne's point and also recalled that the default was 6 months 
de-facto used, and Tim had proposed more than 3 years ago that 3 years 
should be the default for complicated ballots.


Ryan replied that we said 90 days and he could dig up the archives. Tim 
said that he wouldn't be surprised if at different times, different 
people proposed different timelines but 6 months is the number he 
recalls as the agreed upon timeline.


Ryan said that the goal is not to produce a big impact in February but 
rather get some concrete data so we can find the right timelines. Also, 
if CAs ask for specific time to gather information, that would be very 
reasonable and helpful. He is concerned about some CAs using these 
validation methods to issue wildcard certificates which exposes users at 
a greater risk. Some CAs have been conscientious about the discussion in 
Virginia and taking the right steps for not using these methods for 
wildcard certificates.


- Extensions based on BRs 7.1.2.4


Dimitris asked why using the cabfOrganizationIdentifier extension with 
the validation rules described in the EV Guidelines would not be 
considered acceptable for the OV level.


Ryan replied that there is no blanket "yes/no" answer because it is the 
CA's burden to demonstrate how it meets 7.1.2.4 a and b. Tha CA can't 
make up their own rules. Even using the same extension OID that is 
specifically designed for EV Certificates in an OV Certificate might be 
considered to fail b (misleading). In the email there was an example to 
use orgId and there was extensive discussion in the context of LEIs and 
why there has not been any acceptable method proposed that can 
demonstrate both that the Applicant is entitled to assert that 
information and that this information has been appropriately verified. 
The current proposed methods to verify the organization identifier do 
not meet 7.1.2.4 a or b. Some private EKUs have also been included and 
CAs have demonstrated how 7.1.2.4 a and b apply. It would be best to 
start from a position that this is not permitted and work to demonstrate 
how 7.1.2.4 a and b are fulfilled.


Dimitris clarified that he had VAT in mind, because that's in the 
current EV Guidelines so it is used in the public Internet, with clear 
validation rules so why can't a CA use this in an OV Certificate.


Ryan said that the link between the VAT number and an organization 
relies on the strong organization validation that is described in the EV 
Guidelines. The same level of assurance for organization validation does 
not apply in OV Certificates. If a CA uses this information in an OV 
Certificate, they have to demonstrate that that validation is the same 
but in the example Dimitris gave this is tied to an EV Certificate. You 
can't just take EV extension data and move it to an OV Certificate.


Tim commented that what Ryan said means that using an EV validation 
method for an extension related to an OV certificate in an OV validated 
organization, the validation method used is "too good" for an OV 
Certificate.


Ryan clarified that the ability to validate a VAT number is tied to the 
stronger validation method done for the organization. The same problem 
was with the LEI. How do you match that the LEI number is actually 
issued to the organization asserted in the subject and this is where LEI 
is messy because you need to figure out how to do that mapping. VAT is 
roughly the same. You have an organization validated to some level, OV, 
that doesn't give as strong validation as EV that you are actually 
dealing with the specific organization referenced in that VAT number. So 
you can't just add the VAT number because in order to validate that it 
assumes you have strongly validated data to match against which is the 
output of the EV Validation process.


Tim disagreed. Validating an organization at the OV level means that the 
identity of that organization has been validated at that level. So we 
already have an organization there and we just need to validate the VAT 
number against that organization. The level of rigor is that of an OV level.


Dimitris added to Tim's point that once an organization is validated at 
the OV level, the mapping between the organization and the VAT number is 
easy.


Ryan responded that there are different levels of organization 
validation and the orgID and the corresponding extension relies on the 
higher assurance organization validation following the EV process. The 
specific example that Dimitris described is not allowed. In any case, he 
suggested that any CA should consider that something is not allowed and 
work on the 7.1.2.4 language to demonstrate that it meets the 
requirements. Fully copying an extension specifically designed for an EV 
Certificate described in the EV Guidelines and using it in the BRs does 
not automatically meet 7.1.2.4 requirements and Ryan believes it 
misleads Relying Parties about the information verified by the CA, 
because it’s an extension defined for EV certificates. The CA also needs 
to demonstrate that this extension is technically relevant in the 
context of the public Internet, which is not just “it’s useful”.


Alternatively, if it’s not technically relevant to TLS certificates, 
then you can include it as an extension OID that is specific to each 
Applicant, as discussed in 7.1.2.4(a)(i). However, you can’t just reuse 
existing extensions from other profiles, because of 7.1.2.4(b), and for 
something like VAT numbers, it doesn’t pass the sniff test for 
7.1.2.4(a)(ii)


- Certificate Profiles


No specific progress on the certificate profiles.


Ryan reported that automation landed in the servercert repository to 
automatically build docx, pdf versions. Ryan tested tables with "column 
span" and other formatting approaches trying to improve readability and 
preview how things look in the produced pdf, docx files. "Column span" 
is currently not supported as it does in the spreadsheet. Pandoc added 
support this past July/August but it's not yet integrated in the 
"pdf-writer" or "docx-writer".


Everyone that syncs/forks the servercert repository should be in a 
position to see how PDFs are produced and tweak the markdown for better 
table representation.


Tim asked Ryan how frequently do we use "Column span" on the produced 
docs. Ryan said the current documents don't support it but the Google 
spreadsheet uses it extensively. He is still working on these tables to 
find a good solution.


The Subcommittee decided to cancel the call on December 31st.


Next call is scheduled for the Dec 17th


Adjurned




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201218/24aa02ed/attachment-0001.html>