[cabfpub] Notes of meeting, CAB Forum, 11 July 2013

[Ben Wilson]

On our call last Thursday we skipped over approval of the minutes, but here
they are (unapproved) from the previous telephone call.

 

[cabfman] Notes of meeting, CAB Forum, 11 July 2013

Notes of meeting

CAB Forum 

11 July 2013

 

1.   Present:    Kirk Hall, Atsushi Inaba, Ben Wilson, Dean Coclin, Rick
Andrews, Rich Smith, Eddy Nigg, Geoff Keating, Mads Henriksveen, Wayne
Thayer, Jeremy Rowley, Steve Roylance, Gerv Markham, Mert Ozarar, Robin
Alden, Phill Hallam Baker, Cornelia Enke

 

2.  Agenda review:  The agenda was reviewed.  Steve Roylance said he wanted
time to discuss technical constraints.  Jeremy Rowley said he wanted time to
discuss what defines an SSL certificate covered by the Baseline Requirements
and convening the working group on EV.  Rick would like to see if there is
any update on browser vendors using CAA.  He said it seems like Google has
already implemented it.  He asked Geoff whether CAA testing was on the radar
for Apple, and Geoff said it was.

 

3.  Minutes of 27 June 2013:  The minutes were approved for publication as
circulated.

 

4.   Ballots:   Ben- Ballot 104 passed.  Ben will revise 103 again and send
it out again, hopefully this afternoon.  Dean indicated that Oracle is still
interested in joining the Forum.  Dean noted that sent an email response to
Richard from WoSign to submit an application and he hasn't heard anything
back.  Ben will send an email asking for when that might be.  Dean said they
indicated they would join the CAB Forum once they have an approved root.

 

Kirk asked whether the adoption of Ballot 104 immediately allowed automatic
verification by email now since now a two-person vetting requirement for
this validation step would be nonsensical.  Because that is not vetting per
se, is that outside the two-vetter requirement?

 

Wayne- just to clarify the scenario, are you talking about when a person has
a multi-domain / multi-SAN certificate and just want to add a new domain
name to it?

 

Kirk - no, we just changed the EV rule on how to verify a domain, at the EV
level, for a customer.  It used to be that you had to do a manual lookup or
do various things, and a second vetter, Vetter2, however you do it, when
confirming whatever Vetter1 did would check it and confirm that it was
correct. Since the automatic email method allows you to send a challenge
email to confirm domain validation, and it is added to the OV account and no
further vetting is done, it just happens automatically.

 

Steve - It seems that Vetter2 is checking on everything that Vetter1 has
done and is pulling in all of that information that has Vetter1 has
collected.  

 

Jeremy - That is where 11.12 comes in and says that Vetter2 has to review
the entire corpus of the information.

 

Kirk - so assuming your process is sound, then no one, neither Vetter1 nor
Vetter2, has to do anything to add a domain at the EV level, is that what
you were just saying?

 

Steve - Vetter1 has to make sure that he has the results in the system and
Vetter2 does too.

 

Ben -- It is important to remember that the domain validation step is just a
narrow part of the EV guidelines and it doesn't mean that other things still
don't need to be done pursuant to the EV Guidelines.  We can't give
recommendations on whether a process fully satisfies the EV guidelines.

 

Kirk - If no human is involved, then all that is required is that someone go
in occasionally and look at the database and say, "Oh, look, here is another
domain."

 

Ben disagreed.  The use of the phrase "automatic method" starts to imply
that an interpretative opinion is being requested.

 

Wayne - There may be a gray area.  I think the point is that you still have
to do a correlation of all of the information in the certificate, but what
about the case of a multi-domain certificate where you are just adding or
removing a domain?  My interpretation of the guidelines is that yes, you
still need to do that, the guidelines do not allow the automatic process to
replace that final step.  [Narrative Summary by Ben:  So we may need to put
in a better explanation of what to do in this situation because that final
step of due diligence / cross-correlation may not need to happen if the only
change is an automated one.] 

 

Ben - If someone thinks that the current statement of the requirements is
unclear, then the burden is on the ones that feel they need clarification to
propose an amendment to the EV Guidelines.  

 

Steve- I think that is similar to something that I tried to raise in Ballot
92 that was shot down,  

 

Ben- It does. This is also related to the request that we start a working
group to review the EV Guidelines and identify where things don't quite
work.

 

Wayne offered to give Kirk an example offline of how he could validate
things given the passage of Ballot 104. 

 

Rich-  asked when this process could be implemented.  Jeremy said Ballot 104
was effective immediately.  After a short discussion on audit / EV
compliance , it was recommended that CAs have a discussion about this with
their auditors, if needed. 

 

5.  Critical Name Constraints / Technically Constrained Sub CAs.  Steve-
hopefully everyone's had a chance to look at the emails I sent.  Geoff,
could you provide a short response, if you can, on Apple's plans regarding
name constraints?  Gerv - it would be very helpful if Apple could provide us
with its plans on implementing critical name constraints.   Geoff - we don't
have anything to announce other than we do have a bug open on this topic.  

 

Steve - Thanks, I didn't mean to focus this on Apple other than for the
purpose of pushing this ballot forward in order to protect as many people as
we can.  If we can move this forward then we can increase the use of name
constraints and that may give more impetus for other to want to protect
relying parties by recognizing name constraints as well.   Apple would not
vote in opposition to the ballot, but may not vote in favor of it either.  

 

Rick - Since adoption by CABF is not the final step in implementation,
because some browser programs may disagree (e.g. and still require audits),
then getting this into the Baseline Requirements might be insufficient.  

There have been a few cases where the browsers require extra or less than
the Baseline Requirements.  For instance, here Mozilla has said it will
accept name constraints in place of audits, an approach that another browser
might not follow.

 

Gerv - A lot of requirements evolve out of implementation by browsers first.

 

Rick --  We need browsers to all be on the same page.

 

Steve - Ryan Sleevi isn't on the phone, but I think we need clarification
from him because I believe he indicated at some point that he did not
believe that the BRs applied to Sub CAs, which is contrary to most of our
understanding. 

 

Gerv- we see this as a cheaper way to get more people to use SSL, which is
what we'd like to see.  

 

Ben - Rick, does Symantec have concerns beyond the across-the-board
recognition of critical name constraints by browsers?    If we can satisfy
that, is there something beyond that issue? 

Rick - I think Mozilla and Microsoft have now said that external sub CAs
should be treated just like regular CAs, above and beyond the BRs, and
that's what they have put in additional language referring to that. 

 

Eddy - I think that language preceded the BRs.  Gerv, maybe this should be a
ballot brought forward by Mozilla.

 

Gerv is going to talk to Kathleen about endorsing Steve's ballot.  

 

Ben- one of the action items might be for the CAs that support this ballot
to have a side conversation with Google and Apple to understand their
positions better and see whether we can reach consensus on this.

 

Steve- I was looking at this sub CA issue with Ryan, but I've always taken
the position that external sub CAs that are technically constrained should
have easier audit requirements and name constraints are a powerful tool.

 

Ben - We could do this first as a policy adoption ballot and then follow
with another ballot that changes the BRs.

 

Steve- I prefer to do it all in one go. If it fails, we can go back and
separate out the more controversial aspects if there are any, but I think
it's a good ballot, and I know people are worried, and that's why we've made
changes as we've moved this forward.

 

6.  EKUs  and What is an SSL Certificate subject to the Baseline
Requirements:  Jeremy - an interesting question- what really brings a
certificate under coverage of the Baseline Requirements as an SSL server
certificate?  The BRs aren't entirely clear about what the SSL certificate
should / should not contain.  Sometimes you see a certificate with all kinds
of EKUs, but there is no requirement.  Is it just the server authentication
EKU that makes it an SSL certificate?  And what if there's no FQDN?  What's
everyone's thoughts on that?   What makes it fall under the BRs?  And which
EKUs should be allowed and prohibited, and if prohibited then what?

 

Rick feels strongly, there should not be any other EKUs than what is
specified in there.  He sees some customers, e.g. VMware, that use the SSL
key to encrypt some configuration data.  That's pretty dangerous.  The more
you allow a key to be used for other things, the more you open yourself up
to attacks like the FLAME attack.  Right now CABF guidelines say it should
not contain any other EKUs.  

 

Because we've run out of time on this call to discuss this in more detail,
Jeremy will post this topic to the mailing list for further discussion.  We
can discuss it on online and on the next call.

 

7.  Committee to Review EV Vetting:  Jeremy- we had talked about setting up
a working group for EV validation.  He emailed Wayne a request for a new
email list.  Wayne will create a list starting with a half dozen people ---
Sigi, Simon, Melih, Moudrick, Robin, Rich, Eddy, Tom, Jeremy, Kirk, and
Wayne. 

 

8.  CAA:   Rick -  As we discussed previously, in Munich we talked about CAA
and wanted to get feedback from browser vendors who have implemented it and
indicate how onerous it is to create one.  Gerv said Mozilla's approach was
to lock it down at the root to prevent wildcard issuance and then lock down
the high-value targets by naming Mozilla's two CAs one by one.   That is a
good way to do this incrementally.   Phill noted that the WebSec Group has
been discussing certificate pinning recently.  One issue that came up is--if
you're pinning to a CA, how do you identify the CA that you're pinning to?
This turns out to be a little more complicated than might be apparent.  He
recognized that the issues were similar to those in CAA, so he proposed that
they use the same approach as CAA, i.e., a domain name held by the CA.  For
certificate pinned to a CA to work, it is necessary for the browser to map a
CA identifier to the root from which they are allowed to issue, and that
will be in the browser already.  This requires that there be formalization
of a consistent set of labels for purposes of CAA and pinning so that
everyone isn't creating their own schema.  IANA doesn't want to handle it,
someone else will have to.

 

9.  Ankara:  Dean - We could hold the working group meetings on Tuesday.
The CABF Meetings would cover all day Wednesday and Thursday.   Dean will
follow up with Mert and Atilla.

 

10.  Next Call - July 25th.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130729/1032be69/attachment-0002.html>