[cabf_validation] Minutes of the Validation Subcommittee, Dec 19th, 2019
robin.alden at sectigo.com
Thu Dec 19 10:29:09 MST 2019
Minutes of the teleconference of the Validation subcommittee meeting held on
December 19th, 2019
The anti-trust statement was read by Tim.
* Method 6
* ICA subject fields ballot
* Making progress on ISO3166-2 'State or Province' proposals
* Wayne's proposal for supporting .onion names for EV certs
Tim: Just waiting for people to comment on Doug's draft from a few weeks
Doug: I just sent that out again to the list so it is on top of the email
Would welcome help with github. May reach out to JHA for github help.
Tim: I may be able to help with dropping that into Guthub.
ICA subject fields ballot
Tim: We have an idea of what we want to do, but no ballot text has shown up
I'm thinking of putting something simple out on the list.
A moratorium on new fields + a grandfathering in of existing fields.
Ryan had worked on language around 'If it has historically been in an ICA'
We will need some language around what sort of ICAs will qualify for the
Perhaps 'an ICA that is trusted by at least 1 cert consumer and was issued
Tim will get an initial draft out, maybe tomorrow, to get us out of the
Tim is open to fine tuning the language. We need to get something out so we
can move forward.
Tim H and Wayne were discussing on-list. Wayne did not recall the detail.
Tim will dig out the email and we can follow-up from there.
Wayne: I had been contacted by the folks at Tor a while back and again a
They have folks who want to run websites over Tor, but are unable to
advrertise the services because they can't get an EV certificate.
I sent an email on this to the list last night.
The original argument for adding the appendix for Tor certificates to the
EVGLSs bask in 2015 was that the crypto algs used for the Tor address were
insecure. It relied on RSA1024 and SHA1.
We created a special appendix in the EV guidelines that permits Tor
addresses in EV certificates.
There is now a new version of the Tor address spec. Many sites use the new
version. The old version also still exists.
I propose that for V3 onion addresses we allow any type of certificate to be
These include the full 256 bit hash of the certificate in the address, so
the original cryptographic issues are gone.
V2 onion address - can work as today with EV.
If you have a V3 onion address you could get a cert under BR or EV.
For V3, you would not have to put the additional extension in the cert (as
presently required) because that extension contains the hash of the
certificate which would be redundant.
I proposed a new appendix in the BRs that describes what you have to do to
get a valid onion address and I think there are potentially 3 validation
22.214.171.124.6. with Doug's ballot, I will have to make sure this transitions to
Maybe we just hold off on the onion ballot and we start out referring to
The EVGLs Appendix F points out a method for validating control of a Tor
address using a signed CSR. Given that it is already in the EVGLs I don't
see a problem with putting that into the BRs.
I will just copy that wholesale from the EVGLs.
The current method 10 is viable for Tor. We know that Method 10 is on the
way out, but does anyone know if there's any progress on the RFC being
I've chosen to leave that out for now, but could incorporate as part of the
ballot to replace method 10.
I would appreciate feedback on this proposal.
If no significant objections, I would welcome endorsers.
Tim H: TLS-ALPN is stuck at IANA. The RCF as a whole is stuck in one of the
later stages of IESG review process. ETA 1 month or 2.
Dean: Is this to allow .onion names to obtain DV & OV certificates?
Wayne: This is so they they could get DV/OV/EV certificates. Some of the
folks that run Tor sites don't have organizations that would allow them to
get an EV cert. There is also an issue of being able to economically get a
Next meeting, 2 weeks, on January 2nd.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5711 bytes
Desc: not available
More information about the Validation