[cabfpub] Notes of meeting, CAB Forum, 7 March 2013, Version 2

[Ben Wilson]

Here are the minutes of the penultimate CAB Forum telephone call.

 

Notes of meeting, CAB Forum, 7 March 2013, Version 2

 

Notes of meeting

CAB Forum 

7 March 2013

Version 2

 

1.                   Present:  Rick Andrews, Atsushi Inaba, Dean Coclin,
Ryan Koski, Atilla Biler, Jeremy Rowley, Gerv Markham, Brad Hill, Ryan
Sleevi, Ben Wilson, Rich Smith, Wayne Thayer, Phill Hallam-Baker, Mads
Henriksveen, and Cornelia (Connie) Enke

 

2.                   Agenda review:  The agenda was reviewed and approved.

 

3.                   Approve Minutes of 21 February 2013:  The minutes of 21
February 2013 were approved as published.

 

4.                   Review of Ballots:  Ben stated that Ballots 96, 97 and
98 all passed.  He didn't send out an announcement yet that Ballot 98
passed, but he will.  Straw Poll for the meeting in Turkey, Ben has not
tallied up the total, but he thinks that B and C are in the running and that
B is the choice.  He will confirm it and send out an email.  

 

5.                   NIST Workshop panels:  DigiCert joined in 3 panel
submissions that were accepted.  One is the work of the CAB Forum, another
is on certificate transparency, and he thinks another deals with things
going on with the Federal Government.  On the CAB Forum Panel, Ben assumes
Andrew of NIST will be in charge, and that Arno Fielder of ETSI and Jens
Bender of BSI are the others on the panel.  Each presentation is for 20
minutes, so it will be a rapid-fire discussion of various issues.  Ryan
Sleevi said that Google had its presentation on Certificate Transparency
accepted and will address the technical and implementation side.    Dean
noted that the Draft CP is in the preliminary stage right now.  It was
developed in conjunction with an industry-government group of people
including most of the browsers and large corporations as well as big
government agencies. Everyone involved in the CP discussions so far is well
aware of WebTrust, ETSI, CAB Forum, baseline requirements, the security
documents, etc.  The intent of the group has been to fill in gaps-that is
why the CP does not address identity vetting in detail.  The final version
will come out on the NIST day in April where there will be a formal request
for comment.

Connie commented that we should have a summary of all of the requirements so
that there are not such a bundle of documents.  Ben suggested that we put
this (coordinating requirements) on the agenda for the meeting in Munich to
see how far we can get creating a summary of requirements.

 

Phill said that when the Department of Commerce is serious about things it
usually holds two workshops.  They will hold a first workshop that is from a
wide range of directions and they will take written submissions.  Then they
will hold a second workshop that is a bit more specific.  That's what they
did to try and address spam / unsolicited email.    Brad thinks that the two
requests are originating from two different places in the government.  The
CPS and related documents are originating out of the NSA, and the workshop
is originating out of the Department of Commerce.  Ben noted that we're
faced with a problem in this industry in that we are hit by so many
different vectors.  It would be nice if all of the vectors could come
together so that what we're expected to do would be more uniform.

 

6.                   ICANN Letter:   Ben will finalize the ICANN letter and
send it out today.  He is not going to send it out for a final vote.  Phill
suggested that we post the letter on the website so people can be aware of
how we feel and to raise the profile.

 

7.                   IETF:  Phill, Jeremy, and Ryan S. are going to the IETF
meetings next week in Florida.  A report on the results of the IETF meetings
will be put on the next agenda.

 

8.                   Java default configuration issue:  Ben mentioned that
Java's default configuration is to not check certificate status, which is
not good for code signing.  You have to go into the control panel for Java
and manually configure it, which nobody does.  Also, if you have a trusted
certificate and the code is signed, Java doesn't give the user any warning,
it just installs.  So Oracle has simply adjusted the risk profile without
revocation checking there is no true corresponding benefit or compensating
security measure.    Ben had asked the W3C app security group whether a
review of this was within the scope of their charter, and Brad had replied
that it was not.  Java Oracle maintains its own trusted root store.  Rick
noted that he had met with some Oracle folks at RSA and he told them about
the CAB Forum and had expressed an opinion that they should participate.
Ben asked that Rick pursue them a little bit more given the light of this
because Java/Oracle sounds like a good candidate to join the Forum.

 

9.                   Requests to join / Requests to translate guidelines:
Dean and Ben have created a template form that goes through what it takes to
become a member of the Forum, if anyone needs a copy, contact one of them.
We have not heard back yet from the Estonian CA or the Korean CA that we
have replied to.  With regard to translation requests, a few members had
asked Ben to follow up with the Japanese CAs to see about obtaining the most
recent Japanese translations of the guidelines.   We have had difficulty
recently communicating with the Japan CA Forum.  Dean agreed to follow up
with Yoshi to see if we can get a copy of the more-recent Japanese
translations of the guidelines.  

 

10.                1024-bit Legacy Roots-Bruce Morton issue:  It was noted
that there has been a lot of discussion on the list.   Jeremy noted the
issue was that since it's publicly trusted it might be subject to certain
requirements.  That's something they have to work out with the application
software vendors.  Publicly trusted is defined as a certificate that's
chained to a root embedded in a trust store.  

 

Dean said Symantec has the same issues.  His understanding is that these
customers have to use these devices and that there is a particular root that
is embedded in the device and that's the only one that they will trust, and
therefore they can't go off of a private hierarchy because there are
millions of these devices out there already with the embedded root and that
for most there is no connection to the public internet, and therefore these
certificates will not be seen in the wild.

 

Jeremy stated that is correct, but that doesn't exempt them from the
Baseline Requirements, if they want an exemption from the Baseline
Requirements then that is something that they have to bring up with the
application software vendors, not the CAB Forum.  They could bring it up
with the CAB Forum, in the form of a proposed amendment, and they already
have the proposed amendment for the exceptions under section 12, but what
they're looking for is an exemption to the 1024-bit requirements.  

Opinion is split a little on whether application software vendors can say it
is OK as long as the CA does not include the CA-identified Baseline
Requirement OID in the certificate, versus whether the CAB Forum should do
an amendment to permit those kinds of certificates.  

 

One position is that the CAB Forum should be creating exclusions so that
these are truly baseline requirements, while the other position is that the
CAB Forum should not be creating exclusions because there should be baseline
requirements and the more we make exceptions to these things the less it
looks like baseline requirements and the more it looks like CAs are just
putting in all of their practices that they want to as they come up with
them.  Another argument is that allowing certain exceptions may cause
favoritism towards some CAs over others just because they are older.  

 

Ben wondered whether application software vendors should be polled on the
issue, for example, having the CAB Forum recognize that certain legacy roots
were embedded in applications before the baseline requirements, and
grandfathering the root that was embedded before X day by Y application
vendor, based on the application vendor's say.  He also said he thinks that
this issue will resolve itself over time.

 

Dean said that time is of the essence.  There are immediate issues for new
certificates that are issued off of a new hierarchy that would fall under
the BRs and be subject to the new rules, but obviously the devices in
question can't handle either the key size or other roots and so there's no
choice in this matter.  He's curious about what browsers and third parties
have to say on the issue.  Ryan S. said that  Jeremy captured his position
pretty well.  Either we're putting exceptions in the BR that lets a vendor
be BR compliant, and then it falls upon the root stores to set their
requirements which are BR plus x, y, or z.  Or we incorporate x, y, and z in
the BR and the application vendors have to say you're not compliant with x,
we understand that, and we'll make an exception.  There have already been
browsers that are already granting those exemptions from the BRs.  Both
Microsoft and Mozilla have put forward certain parts of the BRs that they're
willing to overlook for a period of time while working through compliance
issues.  

 

Application software vendors may be able to address these issues with
blacklisting a particular hierarchy as an alternative to putting exemptions
in the BRs.  "For example, while it's a publicly trusted root, it's no
longer a concern for any of our application products because anything issued
beneath this particular chain--which supposedly should never be seen on the
internet--will never validate with our product."   The reality is that the
application vendor would need to understand the risk profile presented to
the application's users.  The situations and risks are going to vary
depending on what exemption is being requested, and that may depend on
working with the CA in understanding the relationships that browsers have
with their users and the openness of their root programs.  For example,
Mozilla is very transparent with their root program and very community
involved.

 

The CA Browser Forum would really like to hear from all browsers on this
issue.  From the relying party perspective, Brad said he didn't have strong
opinions one way or the other, but that he doesn't think that there should
be devices 10 years from now that only have 1024-bit keys and that maybe
this is a good forcing function.

 

11.               39-month issue for information about existing customers
raised by Don Sheehy:  Gerv talked with Kathleen. They don't have a strong
opinion, in that this isn't data they primarily present in the primary UI to
the user, he doesn't think they should change the BRs, and they think that
the interpretation is right that you need to do it, straight up, not just a
39-month period of bringing it in, but he would also accept that as an
exception on the audit.  Don was not on the call. Ryan S. said he liked
Gerv's response and that the Mozilla policy reflects Google's position on
this.

 

12.               Status of website rewrites:  Ben said he hasn't had any
time to do editorial improvements to figure out how it should all go.  He
would like to start to put some of that content on the site as it is now,
and restructure the site before we hand it over to anybody else that might
help us improve it.   As long as it doesn't change the navigation of the
site, everyone agreed that we can add those things.  Ben will publicly post
things either in a batch, or major things in a single email.  

 

13.               International Domain Names and Unicode Spoofing:  Brad,
Rick, and Geoff have communicated a little on the issue of the Unicode
code-checking program and whether or not it was going to be delayed.  Brad
said that Google had already submitted another implementation to check for
spoofing to ICU that he would circulate to the mailing list, which he did
immediately following the call.

 

14.               Code signing discussion:  Dean gave an update on the
Baseline Requirements for code signing project.  He noted that at the
face-to-face meeting in Mountain View, we had decided to start a code
signing authentication working group to try to address some of the issues
that have come up with code signing authentication.  The goal is to come up
with some kind of baseline requirement for code signing authentication.
There are a lot of people who have volunteered to be on the committee.  Tom
Albertson volunteered two people from Microsoft, Ryan from GlobalSign,
Jeremy and Ben from DigiCert, Rick and Robin from Comodo, Arno from
TSystems, Kirk from TrendMicro, Connie from SwissSign, and Mert from
TurkTrust. Jason Crawford from Symantec will be leading this effort. Wayne
and Dean will start an email list.  Ben suggested that there be a bi-weekly
meeting when the CAB Forum isn't meeting.  Dean liked the idea.  The charter
is to look at the current Microsoft and Mozilla requirements and recent
incidents to see where things went wrong and to engage in potential
information sharing.  There is a base draft document on the wiki for code
signing that we'll look at.  The goal will be to start work on something,
meet for a half-day session at the Munich meeting if possible for whoever
can attend and work on a goal of coming up with a baseline document.

 

15.                OTA  CA Best Practices:  The OTA has published a CA best
practices document.  It includes a pledge or self-assertion of adherence to
CA best practices, mainly based on the CAB Forum's security requirements
document.  Ben has a draft that he will post to the list that is pretty much
final, but he would like to solicit comments from the CAB Forum on the
pledge. There may be concerns about committing on paper, but the pledge will
not be posted on the Internet.  The OTA web site will say, "The following
CAs have agreed, accepted and endorsed that these are CA best practices."
Ben will circulate the pledge for people to take a look at.

 

16.                Meeting adjourned until the next call - Thursday, 21
March, 2013 (please note that your local time may have changed due to
daylight savings).

 

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