[cabfpub] Notes of meeting, 21 March 2013

[Ben Wilson]

All,

Here are the meeting notes from the CAB Forum’s penultimate call, held on
March 21st.  

Cheers,

Ben

 

Notes of meeting

CAB Forum 

21 March 2013

Version 1

 

1.                   Present:  Rich Smith, Ben Wilson, Atsushi Inaba, Mads
Henriksveen, Sissel Hoel, Eddy Nigg, Robin Alden, Dean Coclin, Wayne Thayer,
Håvard Molland, Phill Hallam-Baker, Rick Andrews, Atilla Biler, Brad Hill,
Geoff Keating, Kirk Hall, Jeremy Rowley, Cornelia Enke, Steve Roylance, Ryan
Sleevi, and Stephen Davidson

 

2.                   Agenda review:  The agenda was reviewed.  Dean asked
that we bring better closure on the issue with re-validation of customers
whose information is older than 39 months.  That discussion was added to the
agenda under Other Business.

 

3.                   Approve Minutes of 7 March 2013:  Ben noted that
reference to an RFI in the Federal Register was mistaken and should be
deleted. The minutes of 7 March 2013 were approved for publication as
amended.

 

4.                   Announcements, Review of Ballots, and Discussion of BR
v. 1.1.3:  There are no ballots pending.  Ben stated that draft version
1.1.3 of the Baseline Requirements has two new tables to address document
changes and implementation dates along with narrative guidance on how to
address audit issues when audit criteria are based on an earlier version of
the BRs.  There were no objections to publishing the revised version except
a minor correction to the spelling of Turktrust, so version 1.1.3 will be
placed on the CAB Forum web site.  

 

5.                   Report on IETF 86 Orlando Proceedings by Jeremy, Phill,
and others:   Phill has talked to Sean Turner about the OCSP must-staple
document and Sean recommended that the references to “policy” be removed, so
he will re-work his internet draft.  

 

Jeremy explained that several CAB Forum members presented at and
participated in the presentations of the WPKOPS Working Group.   One effort
being undertaken is to document browser behavior, but in order to fully
document this, we would want to issue certificates that do not comply with
Baseline Requirements, just to test how a user agent reacts.  There is a
need to have some of them be publically trusted and publicly accessible, as
long as those types are not extremely dangerous, which Phill noted he also
had concerns about.  Ryan S. said that there are some things that can be
mimicked that will allow us to test more dangerous edge cases.   Some things
like caching behavior can be tested in a way that is not dangerous to
potential clients, but how we do it depends on what we need to test.  Jeremy
said that we need to work on a test plan and figure out exactly what we need
to test in order to see behavior.  So we are assembling a list of behaviors
to test, browsers we want to test, and if anyone would like to add
conditions, then they should contact Ben to coordinate.  Ben said that we
would start a public area on Google Drive to share more of this information.

 

6.                   Discuss EV Processing Guideline Recommendations:  Rick
Andrews would like some additional comments to the Guidelines for the
Processing of EV SSL Certificates, v. 2.0.  He has addressed comments and
removed items that could not be agreed upon, then he sent it out and has not
heard from anyone on it, so please let him know if you agree that the draft
should be considered “final”.   Ben said he looked at it and had just a few
comments-- Section 6.2 talks about a root certificate having a designated
OID, but that could be misunderstood as requiring that the OID be embedded
in the root.  Instead, it needs to be revised to make it clear that the OID
is in the end entity’s certificate.   In Section 7 where it talks about
application vendors notifying the Forum, it should highlight that they
should also advise the Forum about all of the other things listed in Section
7, and then Section 7.2 should also say something about the embedding
agreements being non-discriminatory among CSPs.  Rick asked that everyone
get their comments in as soon as possible.

 

7.                   Discuss Technical Constraints in subordinate CAs via
Name Constraints & Extended Key Usage:  Steve Roylance introduced proposed
revisions to the Baseline Requirements to address technical constraints as
presented in Mozilla policy.   The idea behind this is to address various
changes brought on by the Baseline Requirements, which he had raised during
the Paris F2F meeting in June 2011.   We have been moving from what was best
practice to what will be best practice and just like you can’t audit the
world, you can’t audit all sub CAs—so as discussed in Paris, we need to
figure out how to avoid expensive auditing.  In the Mozilla guidelines this
is done with technical constraints--you either need to have an audit or have
technical constraints.   The draft adds a new Section 9.7 for technical
constraints and a new paragraph at the beginning of section 17 to address
the audit issue.  Ben said that there are other sections of the guidelines
that need to be cross-referenced, especially near the top of the document,
and other changes to make this proposal more clear.   Rick Andrews said that
an important concern is that if we allow an audit exception just when a
technical constraint is implemented, then there is no guaranty about the
other things that can go wrong, but he would be more inclined to agree if
browsers were going to do checks for some of the more egregious things that
would also be found in an audit.  Steve said that it will be up to the
audited CA to ensure compliance.  Rick noted that there is a difference
between a technically constrained sub CA that issues just 5 certificates and
one that issues 10s of thousands.  Steve said that in the latter situation,
a CA may want to require that the sub CA to obtain an external audit, but it
would be up to the CA.  Rick said that there are certain things that a sub
CA can mess up on, like key sizes, and other things that still create
external risk that need to be looked at.  Ryan S. said that Baseline
Requirements are a good way of improving the industry across-the-board,
Mozilla is confident in the ability of technical constraints to work, and as
long as we’re not allowing other important things to be skipped, we’re just
narrowing the scope of harm that a sub CA can do, which thereby adjusts the
risk profile, so he thinks he would eventually support this proposal.  Ben
suggested that the CA or auditor could still look at the certificates issued
by the sub CA to determine whether they violated part of the Baseline
Requirements even if the auditor did not get into all of the Baseline
Requirements that are procedurally implemented by the technically
constrained sub CA.  He also said that a flow-down chart could be prepared
to assist with enforcing the BRs on sub CAs.  Steve said that a chart like
that would help explain the BRs to his customers.  

 

8.                   Discuss OCSP Stapling and Short-Lived Certificates:
Jeremy said that this proposal is a follow-up to the recent face-to-face
during which we talked about a gap in the BRs that doesn’t require the AIA
for OCSP stapling and that we also discussed short-lived certificates.
Kirk said that we should make sure we are not being inconsistent with our
support of revocation checking.  Ryan said that he likes the idea of
short-lived certificates but one issue that has not been raised before is
the concern that a CA will mix up certificate profiles in their issuance
pipelines and issue a long-lived certificate without revocation information.
Ben said that this is a valid concern given several instances where this has
happened in the past.  Jeremy said that the Operational Requirements draft
that he discussed previously might be a way to address that risk of
erroneous certificate profiles, but there are serious problems that can
happen in that area besides just issuing a long-lived certificate without
revocation information.  Ryan S. agreed that it is an issue that we need to
address.  Jeremy offered to work again on the Operational Requirements
document with anyone who was willing to, in light of anything new that NIST
might announce in April.   Ryan S. also said that the short-lived
certificates would be on par with other revocation mechanisms because of
similar, related issues experienced with revocation checking on clients with
out-of-date clocks.

 

9.                   Any Other Business:   Dean said that he has learned
recently that there is a huge exhibition going on in Munich the week of our
meeting in June and that all of the hotels he had planned on having us use
are booked, but that his team is looking at the town center for hotels.
However, they have also been either booked or very expensive, so our plans
may have to change.  He will find out more this week and then let everyone
know as soon as he has more information.

 

39-Month Re-Validation in BR Section 11:  As a continuation of the
discussion from the previous meeting, Dean said he would like to remove
confusion about the re-vetting of customers who were customers from before
the adoption of the Baseline Requirements.  Kirk suggested that it be in the
form of a ballot to modify the Baseline Requirements.  Ben noted that in the
previous discussion Ryan S. and Gerv were present, but Don wasn’t.  Gerv had
reported that Kathleen had said that an exception should not be made to the
BRs.  It was generally agreed in the conversation during this meeting that
there was not a clear position from the browsers on what should be done.
Ben said that there may be similar language in the EV Guidelines for
existing customers that might be re-purposed here.   Rick said his
understanding of the exact problem is that in the BRs there is a requirement
that documents originate from an official source, but the allowed practice
prior to the BRs did not require strict recordkeeping on the source of the
documents—so even though they may have the evidence needed, the current
wording implies that they have to re-collect it from an official government
source.   Dean said that he would get together with Don and others and
prepare a ballot.  

 

The face-to-face meeting in Ankara, Turkey, will be October 1-3.

 

10.               Meeting adjourned until the next call – Thursday, April
4th, at the same time.

 

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