[cabf_validation] Minutes of 5th July validation WG call

Tue Jul 17 07:58:12 MST 2018

It's also a pretty standard practice in the standards industry.  I can't
count how many times I've heard "this meeting is being recorded for the
purpose of minute taking".

Most ANSI/ISO meetings follow that practice, for example.

-Tim

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Dean
Coclin via Validation
Sent: Tuesday, July 17, 2018 10:26 AM
To: James Burton <james at sirburton.com>; CA/Browser Forum Validation WG List
<validation at cabforum.org>; Robin Alden <robin.alden at comodoca.com>
Subject: Re: [cabf_validation] Minutes of 5th July validation WG call

Completely disagree. This is not a court or a trial where evidence must be
preserved. In the Forum, recordings are used as an aid to document the
minutes. Once they are reviewed and approved, the recording should be
destroyed.

From: Validation <validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org> > On Behalf Of James Burton via
Validation
Sent: Tuesday, July 17, 2018 9:38 AM
To: Robin Alden <robin.alden at comodoca.com <mailto:robin.alden at comodoca.com>
>; CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] Minutes of 5th July validation WG call

Recordings are pieces of evidence and this evidence should be kept for at
least a 12 months minimum. You might be the best minute taker but sometimes
certain material is lost in translation and this lost material might be
required.

  _____  

From: 30012111460n behalf of 
Sent: Tuesday, July 17, 2018 12:10 pm
To: CA/Browser Forum Validation WG List
Subject: [cabf_validation] Minutes of 5th July validation WG call 

Validation working group, 

5th July 16:03 
A recording exists for purposes of minute taking. It will be destroyed if no
questions arise. 

1. Discuss Wayne's latest validation OID proposal 

Tim recapped that the original validation proposal required OIDs in CA
certificates, which is undesirable. 
Waynes new proposal (in email sent on 23rd June) proposes putting validation
method into the cert only into the end entity certs. 
It is another non-critical extension to specify the method or methods. 

We discussed whether OIDs needed to change when BR versions changed. 
It was suggested that the OID only needs to change when they security
properties change. 

To issue, (up to) 3 things need to be verified: 
identity 
domain 
authentication & permission to issue 

this will be incompletely represented in the OIDs in the cert, but should be
complete for domain validation. 

Why this ballot? 
Browsers / security researchers / some relying parties want to know, when
they look at a cert, what domain validation method was used. 
If a method problem comes up, they can see all the certs issued with that
method. 
They can decide whether they cause some UI to the browser user when the cert
is used. 
e.g. by X date anything with this method in it has to be replaced. After Y
date warnings or errors appear. 

Allows security researchers to look at which methods are used. Tim was
surprised to see that some CAs use particular methods. 

Further discussion on versioning shows the issue of version skew is not yet
completely defined. 
Tim: Lets say we decide SMS is a really bad idea. That would show under
method 2. 

Corey: Maybe that's a symptom of the methods being under-specified. 

Tim: Method 1 used to be 3 different methods. We pulled them out and made 1
it's own top level method. 

Bruce: or we change method 2 to say it is only (sub 1 and 2) and no longer
3. 
Tim: So maybe we make the OID include the sub-method. 
Bruce: relatively easy without creating new methods. 
Tim: This interacts in interesting ways with restrictions to validation
methods from CAA. If we change method identifiers, customers have locked
themselves out.. 

This will be encoded in a new extension, not in the policy OID. 

Bruce: Is there enough time? Apr 1 2019 - 9 months. Is that enough time..?
Does it need pressure on time? 

Tim: 6 months is about right for a non-hard change. 

135 CAs in MS program. 30/40 in CAB forum. 3/4 make comments. Do some of
these things impact a huge number of silent CAs? 
What about the CAs not following along..? 

Tim: Many of them are essentially running a system built and maintained by
someone else. 
Q: Is this sufficiently important to say that it must be done in a (short)
period of time? 
A: That's why we vote. 

2. Discuss CONTACT CAA tag 

Tim: Talked to Phil. He's been busy, so no big process. 
Want to get a ballot up. 
Bruce: I was working with Tim, and put in some text for appendix B (CA
contact tag) which can be an email address or a phone number. 
That can be posted as a way for a CA to contact for domain approval. 
I wanted to break it up into email method and phone method, because
complicated to put them together. 
Methods 2 & 3, one is phone, other non-phone. 
Email - getting an email, getting a random value by email. 
Phone - not a random value. 
In both methods, although we talked about the CA contact method, and got
some support, I don't know how useful it is. Who uses Caa at the moment?
Could we use a TXT record as an alternative? 
I wanted to propose we could do one or the other. 
I wanted them to put (if TXT) in a label domainContact= and then put email
or phone. 
Q: What if they were paired with the method? There is a proposal to put the
method in there. 
A: We define what its used for. CA authorization is right for CAA. 

Tim: motivation here is for customers who can't add CAA records but who can
add TXT records. 

It's relatively high priority, because our next most popular method is
method # (email) but losing some of the effectiveness of that because of
GDPR. It's time to get the text finalized and get it out there. 
Some of us might be suffering because we are losing methods all over the
place. 
Aware of comments about DNS TXT, but hope it can still be used. 

3. Make progress on validation method improvements from validation summit 

Let's pick a non-controvertial and non-complicated one through first. 

Bruce: Methods 9 and 10 had problems. There were no moves to block from the
BRs. 
Do we improve 9 or Axe 9? 

A: like it, but I think we axe it. 

Bruce: Maybe we address 10 with ALPN and see if we can extend it to 9. If we
can't fix 9 we should remove it. 

Tim: That's why IO grouped on Trello (9, 10, and ALPN) 

DNS first label: 
_pkiValidation instead of just _. 
But sounds like it should do similarly for CAA - so not so simple. 

Method 3, rules about phone contact. 
5 suggested changes. Let's do this one first. 
If anything is uncontroversial, this one should be(!) 

Regards 

Robin Alden 
COMODO CA 

----------------------------- 

From: Validation <validation-bounces at cabforum.org
<mailto:validation-bounces at cabforum.org> > On Behalf Of Tim Hollebeek via
Validation 
Sent: 03 July 2018 08:55 
To: CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> > 
Subject: [cabf_validation] Agenda 

1. Discuss Wayne's latest validation OID proposal 
2. Discuss CONTACT CAA tag 
3. Make progress on validation method improvements from validation summit 

-Tim 
_______________________________________________ 
Validation mailing list 
Validation at cabforum.org <mailto:Validation at cabforum.org>  
https://cabforum.org/mailman/listinfo/validation 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180717/614eb114/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180717/614eb114/attachment-0001.p7s>