[cabf_validation] Minutes from Dec 15

Jeremy Rowley jeremy.rowley at digicert.com
Wed Dec 21 15:45:25 MST 2016


Attendees: Rick, Tim, Tyler, Ben, Jeremy, Steve, JC, Doug, Peter, Bruce, Li
Chun, Jessica

 

1.       CNAME Validation. The group discussed how CNAME records would work
with inserting a random value. Jeremy asked for endorsers

2.       SRV ballot. Wayne had a change, which was approved. Peter will ask
if they can endorse.

3.       IP Address Validation. Jeremy circulated the proposed ballot. There
are three methods: a) checking IANA records, b) having the CA log in, and c)
doing a reverse IP lookup.  Peter pointed out that simply logging into the
device doesn't show that they have control, just that they can log into the
device. Rick said the user name or password should contain a random value.
Peter pointed out that user names have length limits so we can't use the
standard random value language. Users can change their own passwords so
adding a random value doesn't show they have control. Jeremy will revise.
Nothing in the document requires the IP address be tied to the name. Peter
suggested we copy the language from the domain validation about
authenticating the identity of the organization. 

4.       Subject Information Ballot. Bruce wanted to make state an optional
field. Bruce sent a draft. Bruce has one endorser. Tim wanted to make sure
it was required if there is a state or province. He wanted to continue
thinking about the solution. Tim said the guidelines are unclear when you
need to include a state and when it's optional. Bruce pointed out that we
need this to determine the place of businesses (too many Springfields). Kirk
suggested we keep a list of where we need a state/province. Some countries
have states but don't use them in their addresses. Scott suggested we only
list the countries where state is required. Kirk sent around a list of
postal requirements for different countries. Bruce will look at alternative
language. Peter put together an ANS.1 format to include the BRs that
describe the subject information. 

5.       Validation Sources. Kirk proposed that we create a safe harbor list
where anyone can bring forward a database and present it to the Forum. The
Forum decides after considering the information provided in connection with
the source. The CA can still use a different database if it writes up a
report on why the database is reliable and lists the database in its CPS.
The auditor would then evaluate whether the CA followed the process. The
auditor would not opinion on the reliability of the data source. Jeremy
asked whether this was a problem and doesn't it force the CA to give up
valuable information. Kirk said it did not give up a competitor's advantage
because the CA would still have to do the exercise on reliability.
Government entities would be automatically listed. The goal is to raise the
level of validation and make org validation more standardized.  Steve
suggested we look at reliable methods of communication first.

6.       Ambiguity of 169. Wayne circulated a ballot that clarified reuse of
validation information. Entrust endorsed. 

7.       Required website content. Rick circulated a ballot. Looking for
endorsers.

8.       otherName and rfc822Names. WFA uses otherName to specify friendly
names. Peter suggested that there be validation tied to including this
information. Jeremy said we should leave the validation requirements to the
group requesting the OID. Jeremy proposed requiring email validation in
rfc822 names and then permit other OIDs as requested by different groups.
Peter said we need to specify who uses each OID. Jeremy will circulate
language.

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20161221/61bbf33d/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/20161221/61bbf33d/attachment.bin>


More information about the Validation mailing list