[cabfpub] Notes of CABF Telephone Call - 2 January 2014

[Ben Wilson]

No telephone call occurred on 16 January 2014.  Here are the previous
meeting’s notes.

 

Notes of meeting

CAB Forum 

2 January 2014

Version 1

 

1.  Roll Call:  Moudrick Dadashov, Caroline Oldenburg, Dean Coclin, Atsushi
Inaba, Ben Wilson, Doug Beattie, Atilla Biler, Mads Henriksveen, Sissel
Hoel, Rich Smith, Ryan Sleevi, Eneli Kirme, Jeremy Rowley, Rick Andrews,
Imren Altepe, Robin Alden, and Kirk Hall

 

2.  Agenda Review:  Approved as presented.

 

3.  Minutes:  Minutes of 19 December 2013 were approved for publication as
circulated.  

 

4.  Discussion of Ballots:   Voting on Ballot 113 starts Monday.  Ben will
circulate a redlined version of the language and Ballot 89 (EV Processing)
will be re-introduced today.  Ballot 103 (Must Staple) is awaiting an OID
assignment from IANA/IETF.  Brian Smith will reach out to Sean Turner for
clarification on when that might occur.  Drafting work continues on other
Ballot 107 (removing version specificity for ETSI TSs), 110 (Amendment to
Bylaws), and 112 (Definition of "Internal Server Name").  Discussion of
Ballot 108 (Scope of BRs ) continues on the mailing list and is agenda item
number 6 below.   

 

5.  Upcoming Face-to-Face Meetings: 

The plan for Mountain View will be for working groups to meet on Tuesday,
February 18, beginning with discussions of code signing requirements,
followed by discussions of SSL performance, and then the EV Guidelines.
This will be followed on Wednesday and Thursday with CABF F2F meetings.  For
the Israel F2F in June, currently the plan is to meet in Eilat for the
working group meetings on Monday, June 16, and the CABF F2F Tuesday and
Wednesday the 17 and 18 of June.  People can either fly or bus to Eilat on
Sunday, 15 June, or thereafter depending on each person’s itinerary.  Ben is
interested in finding out who might be interested in traveling to Petra,
Jordan, Thursday (and possibly other parts of Israel through Saturday before
flying out the following Sunday).  Kirk suggested that we ask people whether
they know of any scheduling conflicts or other events during that week that
might create some type of scheduling conflict.  We should finalize this plan
within the next two weeks.  Ben will circulate information about the travel
agency.  A group greater than two people will reduce tour guide expenses.

 

6.  Scope of BRs

Ben opened the floor for a discussion of the BRs and the definition of SSL
certificate.

Ben:  The issue involves what is the scope of the BRs, what is an SSL
certificate, how do SSL certificates compare with other types of
certificates like Qualified Certificates, Grid Certificates, etc..

Kirk:  I think Jeremy was coming close to a definition in a recent email.
We should publicly send it to the browsers and ask them whether they will
incorporate the definition about the anyEKU EKU in their rules.  I know that
Iñigo had concerns.  Would he say that QCs shouldn’t apply to the BRs?  We
should send it to the browsers and at the same time send it to those issuing
QCs.   

Jeremy:  From a practical standpoint, there is a problem because they don’t
qualify under the BRs, but depending if there is a domain name in them, they
could be used for SSL.

Kirk:  They should be compliant, unless they want to change their EKU.
Maybe it will take them some time to become compliant, but we should put
forth a concrete proposal so that we’re talking about adoption or not,
instead of going around and around on this issue.

Ben:  Maybe we make a statement in the BRs that makes it even more clear
that certain types of profiles are clearly not conformant or compliant with
the Baseline Requirements.

Moudrick:  Maybe we should say that they must not be mixed.  The concern as
Jeremy just mentioned is that there is the potential that those certificates
could be used for SSL, but if we say you cannot mix the use for qualified
digital signatures, that might fix the issue.  If QC can be recognized
effectively as a QC for electronic signature, that means then that they
shouldn’t be recognized for SSL.

Jeremy:  They can because they contain the anyEKU EKU.  Any certificate that
has the anyEKU, or lacks the EKU, can be used as an SSL certificate.

Moudrick:  But it depends on how you prioritize the interpretation of the
certificate.  So if we say we recognize it as qualified electronic signature
certificate, then all other interpretations should be irrelevant.  We should
just say they can’t be mixed.

Jeremy:  So if it has the qualified statement in it, that should be the best
solution, but that only excludes qualified certificates.  What if you have
grid certificates or federal government certificates, which are not
qualified certificates, but might have the anyEKU or other profiles that
allow them for use as SSL without conforming to the Baseline Requirements?

Rick:  Can they be used for SSL, rather not “can they”, but “are they
intended” to be used for SSL? Not whether they can be, because Moudrick is
saying they are not intended to be SSL certificates, so if a browser can
detect that they are a qualified certificate, then they should not be used
for SSL.

Jeremy:  Right, but these are not necessarily qualified certificates.  They
are not intended for use as SSL, but they can be used because of the anyEKU
EKU.  My concern is that even if we create a rule for US Common Policy
certificates and for EU QCs, we have to discover all of the others before we
can create a hard-and-fast rule.

Rick:  Can we have a rule that prohibits the anyEKU EKU.  I think the
browsers would support the position that anything used for public trusted
SSL should not be used for anything else, so you could make the argument
against the anyEKU.  So could we phase out the anyEKU in these types of
certificates over time?

Jeremy:  That’s browser behavior, and the browsers have never been willing
to support anything that mandates browser behavior.  And you have the
problem that RFC 5280 requires that you allow the anyEKU to be used for any
EKU, as Ryan S. pointed out in his email.  But, you’re right, because
working with a smaller group of CAs that can manage the use of the anyEKU
would be easier than changing the rules for everyone concerning the anyEKU. 

Ryan:   I can tell you that changes to use blacklist for QCs won’t work.
We’re having this discussion to clarify the scope of the BRs for audit
purposes, so I can understand the goal to find a short solution, but
changing the browsers’ use of blacklists to recognize QCs is not in our
plans.  I am much more in favor of whitelists, and we do not want to alter
behavior contrary to RFC 5280 unless we have to.  I can’t see any short-term
solution, so we need to get all of this discussion out in the open for a
path forward, but I don’t think a black list is not going to be a solution.

Ben:  I don’t see why we can’t refuse to follow RFC 5280 with a resolution
that browsers “should not” allow a publicly trusted SSL certificate with the
anyEKU to be used as an SSL certificate.

Ryan:  RFC 5280 deals with path-building and how that path building goes on,
so we could say that end entity certificate must have the TLS server EKU,
but RFC 5280 says the anyEKU EKU must be treated as an EKU.  With the
Microsoft and Mozilla implementations, there is the EKU chaining behavior,
which in part did not mitigate the Flame attack, because the Intermediate
certificate did have the anyEKU EKU and not just the terminal services EKU.

Ben:  What about saying “if you’re going to have the anyEKU, you have to
have the TLS server EKU as well?” 

Ryan:  We could do that, but we are going to have to look at a large number
of intermediate CAs and address the anyEKU.

Ben:  I know it doesn’t solve the security issue with the intermediates, but
can’t we just address end entity certificate requirements? 

Ryan:  Part of the goal is to define the scope in the requirements to
include the intermediates, because there are parts of the Baseline
Requirements that apply to intermediates.  Once you determine how to handle
multi-purposed intermediates that will help resolve potential confusion
about the requirements.  So there may be need for more discussion on the
list.

Jeremy:  I think it is something we can solve more easily once we convert to
the RFC 3647 format and we can scope the CP to address security and data
protection generally, and then validation requirements and profiles
specifically to certificate types.   All publicly trusted CA should be
protected and securely operated and support the provision of revocation
information.  I say we address it as part of that if we cannot find some
other more immediate solution.

Ben:  We have gone over our time on this topic, but we should look at the
RFC 3647 as part of the new year.  Is there a committee so we can make
progress from call to call.  We need to make progress. 

Jeremy:  If we need to make progress, all we need is someone to review the
documents.  

Ben:  We need someone to take up the responsibility to take a look at it.

Ryan:  I think Tom and I committed to taking a look at it in the new year
leading up to the face-to-face meeting in February.  

Ben:  I don’t want to flood the list with discussion of the RFC 3647 format,
so just to keep a dialog going, maybe those interested like Tom, Ryan,
Jeremy, me and others can keep this moving forward.

 

7.  Pre-Certificates and CT Logging

Discussion still ongoing and deferred for continuation on the mailing list.

 

8.  Working Group Updates               

Dean said that meetings of the code signing group will re-commence.  Of
note, Microsoft would like to explore whether key storage could be required
just on USB hardware, and not necessarily FIPS.  If private keys still
remain on the system then the USB storage just duplicates the risk of
compromise.  The EV Working Group will meet next week (9 January 2014).
Performance Working Group will be looking at certificate profiles and OCSP
to maximize performance of SSL.   

 

9.  Any Other Business:  None.

 

10.  Next Phone Call:  Thursday, January 16, 2014

 

11.  Meeting Adjourned            

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140206/48c6cd93/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140206/48c6cd93/attachment.p7s>