[cabf_validation] Minutes from Validation WG - Feb 23 2017

Jeremy Rowley jeremy.rowley at digicert.com
Wed Mar 8 11:28:42 MST 2017


Attendees: Robin, Peter, Jeremy, Wayne, Ben, Li-Chun, Doug, Dimitri, Tyler

 

 

ANS.1 Ballot - Peter will send

 

Ballot 190 - Add back in two validation methods and fixes a couple of errors
in .well-known.  Looking for one endorsers with Wayne as sponsor and
DigiCert as first endorser. 

 

Ballot 191 - Clarified place of business information in EV guidelines to
match Baseline Requirements. 

 

Ballot 192 - Latin notary update. Expands scope of Latin notaries to
non-Latin countries. Doug will propose. Jeremy will endorse. Wayne wondered
how we would certify that they are an actual Latin notary. How do you
establish they are not just notaries? You'd have to look at the law of the
country.  Wayne suggested we add a requirement to verify the Latin Notary's
authority. Doug will go back and ask their RA what they had in mind for
validating the notary. 

 

IP Address validation - We went over the proposal. There were questions
about how a DNS record works with IP Addresses. Doug raised a concern about
shared IP addresses. This doesn't work well anyway and it's no weaker than
the general problem of content change. 

 

Sub CA content - Is the issue that we want the names to be meaningful?  The
question is whether we want the names to be meaningful and what information
should be included to identify the Sub CA. The question of what is required
in the Sub CA came up on the Mozilla list. We should require the Sub CA to
include a common name that is not misleading. The old language was removed
because an auditor was complaining about a CA issuing a vanity CA. We need
to be careful to not reintroduce the problem with vanity CAs being limited.
Proposal: Require the following to contain meaningful information: Org name,
country name, common name. Additional attributes are okay. Need to be
careful to grandfather people in, including people half way through the
Mozilla process. After we adopt the requirement for the data, we can sort
out the rest of the requirements. It would be nice if we could create a
globally unique name but this is difficult. Ben will draft a proposal for
next meeting.

 

Shared Server discussion - A skilled attacker could redirect a site over to
another and get a certificate using a change in control. Should we address
this? This is similar to shared IP Addresses. The problem is not HTTP, it's
the concept of a default website. Default websites are a fairly common
configuration so this might be a significant issue. There are two ways to
mitigate this: a) don't allow HTTPs (use HTTP for validation) and b)
validate the certificate on the website matches the website.  Wayne will
send out a link to the group on the discussion about the topic.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170308/73aa26a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170308/73aa26a4/attachment.bin>


More information about the Validation mailing list