[cabf_validation] Minutes of 5th July validation WG call

[James Burton]

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> On Behalf Of Tim Hollebeek via Validation
Sent: 03 July 2018 08:55
To: CA/Browser Forum Validation WG List <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
https://cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180717/768b260e/attachment-0001.html>