[cabfpub] Notes of CABF Calls 19 Sept 2013 and 10 Oct 2013

Ben Wilson ben at digicert.com
Thu Oct 24 17:41:06 UTC 2013


All

Attached are the minutes of the last two telephone calls (not including the
one today during which these were approved for publication).

Ben

 

Notes of meeting

CAB Forum 

10 October  2013

Version 1

1.  Present:   Ben Wilson, Stephen Davidson, Eddy Nigg, Rich Smith, Robin
Alden, Eneli Kirme, Dean Coclin, Atsushi Inaba, Wayne Thayer, Mert Ozarar,
Atilla Biler, Hävard Molland, Gerv Markham, Geoff Keating, Rick Andrews, and
Jeremy Rowley 

2.  Agenda review: Eddy asked that the question regarding exceptions to
migration to 2048-bit be discussed.  Ben asked that we add discussions about
the meaning of EV and the definition of application service provider to the
list.  Gerv asked to discuss a new working group on certificate format best
practices.   

3.  Minutes:  Ben explained that he hasn’t typed up the minutes of the
telephone call on 19 Sept. 2013, but he will and circulate them soon. 

4.  Ballots:  Voting on Ballot 89 starts next Monday.  Anyone with comments
to bring them to the list.  Other ballots need to be revisited and
presented.  

5.  Membership applications:   Dean noted that we’ve received the
application from Atos.  They’ve signed the IPR Agreement and confirmed they
meet the bylaws and have passed an audit report, but we are still unclear on
whether they’ve issued any publicly trusted SSL certificates.  There is
nothing under Atos in issuance databases, so it’s possible that they are
listed under a different name.  Dean will go back to them and ask for a
confirmation of this because this issue is similar to the reason why we held
up the application of Affirm Trust.

6.  Bylaws:  As noted in Dean’s email and the draft minutes of the Ankara
face-to-face, we have discussed the participation levels of interested
parties, invited guests, and others.  Dean quickly reviewed the proposed
language.  Dean suggested that we circulate a ballot.  Ben offered to take
the language and redline page 4 of the Bylaws and then circulate that page
so everyone can see what the changes are.  Ben will take the action to mark
up the bylaws.

Ben asked about the issue raised in Sigbjorn’s recent email about whether
Opera met the definition of a browser.  Gerv clarified that the issue was
the use of a definition for application software in the draft
recommendations for processing EV certificates.  Turning to the definition
of “browser” in the bylaws, however, we need to look at this in light of
Oracle’s interest in joining the CABF.   The bylaws define “browsers” as
someone who makes a browser product.  Who we’re talking about are not the
root store operators, but also operating platforms in addition to software
used for browsing.  Ben said we could add operating system to the title
“Browser/OS”.  We might also have to consider the size of the applicant, but
there might be small ones that want to join.  If they become a voting
member, it might have an impact.  This is not trivial, we should take this
to the list.  If they want to join, we should change the definition so that
they fit.  Ben will start a thread on the list discussing this topic.

7.  Review of working group status:  We are moving the revocation working
group discussions to the main public list.  Dean said that for the code
signing working group we had good discussion on the three areas we are
focusing on--private key protection  (there really is an issue with theft
and there have been examples of this previously), enhanced vetting, and
information sharing.

Enhanced key protection with a hardware token or storage in a signing portal
is the recommendation, but to implement such a drastic change, we might be
upsetting current processes.  We will put recommendations out to the list
for comments, then to the public for comment, and then we’ll have a phase in
period over about a year.

Vetting:  This has been a concern primarily in the countries of China,
Brazil, and Korea.  We’re recommending enhanced requirements similar to OV
vetting for all of these.

Information sharing:  provisions for information sharing were preserved in
the draft because we determined that because it was optional and not a
requirement that it would not be opposed because if people wanted to share
info, they can.

So we’ll be coming out with a draft of the code signing requirements.  First
they’ll be reviewed by the Code Signing Group, and then for 30 days by the
Forum, and then by the public for 60 days.   Before we set firm
implementation dates, we’d like to get comments back and specifically target
software developers and publishing houses and get their feedback on the
draft.

EV Guidelines Working Group:  we are going to convert both EV Guidelines and
Baseline Requirements to RFC 3647 format.  Jeremy has both drafts almost
done, and by next call he might be able to distribute them.

New Working Group for Recommended Certificate contents:  Gerv proposed that
a group be formed to address the various performance characteristics to
optimize SSL system configuration so that handshakes and SSL communications
are streamlined.  We should create a working group that gives all of the
possibilities, and keeps track of progress on this topic, etc.  Mozilla and
other people at the face-to-face exhibited interest in having the CAB Forum
publish a set of best practices.  Ben offered to manage a new email list.
Wayne will set it up as cabfperf or performance mailing list.    

First we will need to follow the bylaws in setting up a working group.
According to section 5.3 of the bylaws, the process is to have a ballot to
open up the working group.  Gerv will draft a ballot for the working group.

8. Review other tasks and follow-ups from Ankara meeting:   We need to make
sure we capture all tasks from the face-to-face.  Jeremy is mapping our
guidelines to RFC 3647.  We were also going to distribute the ICANN
presentation and other slides from the face-to-face. 

For continued discussions on transitioning from SHA 1 we’ll need Tom to be
present.  Microsoft was proposing some things that were more aggressive than
what many of the CAs in the CAB Forum are ready to meet.  If those terms
were accepted, then we would have a very short transition period.  At the
F2F we talked about possible requirements to bring in the Baseline
Requirement dates to match Tom’s dates, but we would like to propose to
Microsoft that they move their dates to meet the CAB Forum dates because
Microsoft’s dates are very aggressive.  

Rick would like to propose that all browsers agree on a certain policy
versus every browser having its own implementation policies.

Gerv thinks it will be difficult to convince Microsoft to move its dates.
You might want to take advantage of the next three years and raise the bar
for best practices of those certificates that could include shortening the
life.

Wayne said he had reached out previously to Microsoft on this issue.  He
also asked about the suggestion from the Munich face-to-face that we adopt a
transition plan with SHA2 being offered as a default.  

Eddy said that defaulting to SHA2 will not work because as soon as customers
get the SHA2 certificate they’ll be calling right back to get a new one that
is SHA1 instead.  

Gerv said CAs should develop server patches that support multiple
certificates with the ability to serve up different kinds of certificates
based on browser capabilities.  

Ben asked whether we could create an FAQ about transitioning from SHA1 to
SHA2.

Dean said the Microsoft was publishing an article, but if the article
contains the deadlines, then we’d need to do something prior to that
announcement.  By not publishing it, and keeping with the currently
suggested deadlines, it could make things worse.  

Rick and Wayne will send a message to Tom to see if we can do anything about
it and to see if there is an alternative path forward that lessens the
impact.  

9.  Website status:  Ben said that he broke all of the links trying to set
up the pages as user-friendly permalinks, so he put them back to the way
they were.  The re-indexing is not happening as it should, but he’ll get
some help to figure it out.  Ben also asked Wayne whether we could copy all
of the different versions of the Baseline Requirements and EV Guidelines
from the docs folder over to the media folder so that all of the existing
documents can be linked to from Wordpress.  Wayne said he thought it would
be pretty easy.  Gerv said we need to make sure to create referral links
from our existing URLs.  He also recommended that Ben prepare a punch list
in order to delegate remaining tasks for the website.  

10.  Upcoming meetings:  Our next call is October 24.  Then Nov 7, and it
looks like we can keep on this schedule every other week into January next
year.  We are looking at having our next face-to-face meeting in the San
Francisco area the week of February 17 (the week before RSA).  Google is
going to confirm.  For our June 2014 meeting, Eddy has offered to host in
Israel.  The fall meeting will be hosted by WoSign in China and in 2015 we
have offers from Microsoft, SwissSign to have it in Zurich, and e-tugra has
offered to host in Istanbul in the fall of 2015.  Iñigio/Izenpe has also
offered to host in Bilbao at some point in the future.  Code signing and EV
working groups will meet next Wednesday and Thursday, respectively, and
every other week after that.  

11.  Any Other Business:  Eddy asked about providing a response to the
question about exceptions to 1k certificate deadline.   Dean sent some
questions last night to Eddy that can be used to ask in order to clarify the
question more, because we need to understand that person’s issue a little
better.   Discussion on the EV green bar can continue on the list.  

12.  Next call:  October 24 

Meeting adjourned.

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -

Notes of meeting

CAB Forum 

19 September  2013

Version 1

1.  Present:   Dean Coclin, Mert Ozarar, Atilla Biler, Ben Wilson, Sigbjorn
Vik, Eddy Nigg, Atsushi Inaba, Mads Henriksveen, Sissel Hoel, Rick Andrews,
Geoff Keating, Robin Alden, Cornelia Enke, Jeremy Rowley, Gerv Markham

2.  Agenda: Approved

3.  Minutes:   Minutes from 5 Sept. 2013 approved. 

4.  Discussion of Face-to-Face Meeting Agenda:    We should probably discuss
a little about the NYT/Guardian article on NSA/GCHQ.  What is the global
perspective on this?  Mads said that there was an article in the Norwegian
paper recently.  It’s quite difficult for people like us representing
important parts of the SSL ecosystem, to answer on behalf of all the people
in the ecosystem.  How should these questions be answered?  Some statement
from the Forum could be helpful for us.  The CA Security Council, and
GlobalSign have written posts as a responses to this news.  These may all be
good resources for others to use in response to the questions/concerns.
Besides that, our understanding is that CAs weren't really alleged to have
been involved with the NSA spying, it was more software compromise and
algorithms that might be compromised and this is what we are saying.  Geoff
noted that more than one person is thinking that CAs are insecure, so some
type of denial by the Forum would be smart.  Mads said a statement of what
could be compromised rather than about CAs is a goo approach.   Ben will
send out links to the posts. (Here they are:
(https://casecurity.org/2013/09/13/encryption-still-works-its-about-how-you-
implement-it/#! -
https://www.globalsign.com/blog/trust-the-math-choose-your-friends-wisely.ht
ml)   From the inside we know, but for instance, in Norway, it might be more
difficult to get that word out.  Mads, you could take these responses, and
link to them if you need something to say that these are replies from the
industry, maybe that will work.  It depends on how far you want to go, and
how you want to respond.

Sigbjorn, Rick, Gerv and Connie:  There are issues raised by Bruce Schneier
about whether or not we should raise key lengths or trust elliptic curves
created with Dual EC_DRBG.    I think that was mainly in the context of a
random number generator, not in certificates.  There was a random number
generator that NSA had a hand in generating.    That was the Deterministic
Random Bit Generator (DRBG) Algorithm.  That’s the first issue.  The second
issue is that the constants (curves) for these standards may not be as quite
as secure as we thought they would be.
https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html  The
issue is that because NSA had a hand in selecting the curves, there might be
might an unknown weakness or backdoor for decryption.  The answer is that
nobody uses DRBG, so the concern is only about the curves.  (Speculation is
that they could have been favored based on brute force searching for
constants with certain properties that would give the NSA a head start on
being able to decrypt data that was encrypted by relying on such curves.)

Sigbjorn:  Another topic I’d like to discuss is that some CAs do everything
for the customer, generate private key, public key, and send to customer
encrypted.  If in this process the NSA is able to obtain the private key,
they can then get to all of the communications.  Shouldn’t this be
prohibited?

Eddy:  CAs should be allowed to provide this as an option for customers,
otherwise you’ll have lots of support problems.

Connie:  This depends on the implementation and a consideration of the
architecture of your backend systems and how you are doing this.  We should
discuss this on Wednesday morning.  It could be a problem, because some
customers might really want such a service.

Gerv:  Can the CAs that offer this answer what percentage of customers
request that the CA generates the private key for them vs. those that only
require a CSR?

Eddy:  The majority of our subscribers request that the private key be
generated by the CA—for server certificates.  This might be around 70%. 

Gerv:  Do you think that this is because generating it on the customer’s
server is more complicated?

Eddy:  Yes.

Robin:  We don’t generate keys for our server certificates.  There are some
clients that need us to generate client certificates for them.

Eddy:  We do just the opposite, because the browser software helps customers
generate their own key pairs for SMIME.  

Gerv:  That would be an interesting topic to discuss.  

Ben:  Atsushi has requested that we talk about the use of SHA2 on mobile
devices in Japan.

Atsushi:  Yes, I would like to address the issue of SHA2 in the Japanese
market.  

Ben:   SHA2 can be discussed in the morning, and then the other topics on
the schedule are collaboration with other groups (IETF, NIST, etc.) and then
we’ll talk about interested party and observers.  There is an update from
ICANN as well. 

Finally, we have also invited the audit and supervisory groups of Turkey to
attend the meeting as invited guests.  

5.  Any Other Business:  None.

6. Next phone call:   Thurs. October 10th.

7.  Meeting adjourned.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131024/c69de9f7/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/20131024/c69de9f7/attachment.p7s>


More information about the Public mailing list