[cabfpub] FW: Notes of Meeting - CAB Forum 24 October 2013
ben at digicert.com
Mon Nov 11 21:26:17 UTC 2013
Thanks. I forgot that you had mentioned that previously. The correction
has been duly noted in the official version of the minutes.
From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
Sent: Monday, November 11, 2013 2:11 PM
To: ben at digicert.com
Subject: RE: [cabfpub] Notes of Meeting - CAB Forum 24 October 2013
"Ryan Smith" -> "Brian Smith"
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ben Wilson
Sent: Monday, November 11, 2013 1:07 PM
To: public at cabforum.org
Subject: [cabfpub] Notes of Meeting - CAB Forum 24 October 2013
Here are the notes from our penultimate CA/Browser For telephone call.
24 October 2013
1. Present: Gerv Markham, Eddy Nigg, Ben Wilson, Dean Coclin, Atsushi
Inaba, Wayne Thayer, Jeremy Rowley, Geoff Keating, Carolyn Oldenburg, Rick
Andrews, Stephen Davidson, Tom Albertson, Atilla Biler, Kelvin Yiu,
2. Agenda: Approved as published. (Note - next meeting on 7 Nov 2013 will
be AFTER switch off of Daylight Savings in Europe and North America, so
those who have been on DST will have this call one hour earlier because this
call is always at 1600 UTC.)
3. Approval of minutes: Minutes of 19 Sept 2013 and 10 October 2013
approved for publication as previously distributed.
4. Ballots: Ballot 89 was withdrawn for editing. Rick and Ben were
going to work on it, but they have been busy lately. They'll revisit where
it is and get it out for another review. Ballot 109 - could everyone vote
on that? Gerv has voted already, voting ends next Monday. Ballot 103 -
Ben revisited the current draft language recently. The most recent concern
was that there would not be enough implementation time, but Ben doesn't
think there needs to be implementation time because it is unlikely anybody
would have already implemented Section 13.2.1 the way that the language
suggested it would have been implemented. Bruce Morton had responded that
he thought it might be Verizon who had some problem with not having the AIA
for OCSP. Ben would still like to get two endorsers on it. As Bruce
suggested, he deleted section 3 because it was no longer needed. He will
send it out again seeking endorsement. If anybody has concerns, please let
Ben know, especially the implementation section. He said he is fine with
saying "Effective date January 1 2014" if people are opposed to saying
"Effective immediately". Is there a preference? Does anyone care? He'll
think about this issue a bit more before sending it out.
5. Website edits remaining: Most of the remaining tasks aren't that hard.
Dean will try to go through the punch list later today. Dean will send back
notice by Monday of how far he was able to get through the list.
6. Membership Applications:
CertSign: Certsign sent in their application in, and we went back to them
and asked whether they have issued publicly trusted certificates to public
web sites. They responded affirmatively with examples of websites using
their SSL certificates. In Dean's opinion, they meet the criteria. He
asked that they be approved, but he noted that the bylaws say that a vote is
required, which we have not conducted formally in the past. Gerv suggested
that the bylaws be amended so that new members are approved by the chair
after discussion unless two members object and ask for a vote, then there
would be a vote. So the chair would do the vetting, recommend and take
action unless there were objections. Ben will take that as a proposed bylaw
revision that we can discuss in the next draft circulated. Dean will go
back to CertSign and let them know they are approved.
Atos: Atos has signed the IPR and meets all of the requirements for
membership, but they have not issued publicly trusted certificate to a
public web site. They are in the queue with Mozilla, but are already in
Microsoft. They have issued other SSL certs, but haven't provided a
demonstration that they have issued publicly trusted SSL certificates other
than test ones. Ben said that if they are in Microsoft, they can always
issue a real certificate to a server somewhere that we can see and test with
Windows. Tom noted that we do have the precedent of Affirmtrust, which
wasn't considered a voting member until they started to issue certificates.
Wayne agreed with this approach. Dean said that he would advise them that
they can have observer status until they have demonstrated real certificate
issuance, and then they would have voting rights.
7. Cloudflare request for membership as an interested party: Dean noted
that they've signed the IPR agreement, and it's clear that they can
participate in the new working group being formed. Eddy suggested that we
make sure to send out an invitation to other CDN groups, so that we can have
their input, rather than from just one CDN. Gerv will see if Ryan Smith is
willing to be a co-chair from Mozilla, but the position for two co-chairs is
technically open, so we'll put out a request for nominations or volunteers.
Gerv will respond to Cloudflare and let them know that as soon as we have
the signed IPR, they can participate as an interested party.
8. Mandatory SANS in SSL certificates: Ben said this must be resolved
today one way or another because of an issue that Entrust has. Eddy said
he didn't think it was a highly urgent matter that had to be resolved today.
He said that because it's an application issue, it is in Entrust's client's
power to correct, it's not something that is wrong with the platform. Rick
said that this is a customer that has a large install-base, so it's likely
going to be difficult to change their base, and their not using browsers.
Symantec has the same problem with similar customers. He said that he is
testing with certificates that do not have a server_auth EKU, but instead
have a critical custom EKU, and whether browsers will prevent you from
proceeding with these types of certificates. Rick wondered how other
members of the Forum felt about this solution. Jeremy said that the same
approach was being followed in the NFC Forum. He wasn't sure whether they
were making it critical, but it was being designed to make sure that the
browsers wouldn't trust it. Wayne said we need to amend the Baseline
Requirements, because since these certificates come off a trusted root, then
CAs will likely find it difficult to explain to auditors who might not
Some points were added: the BRs don't apply currently to code signing
certificates, so they would not be subject to the BR audit; maybe the CA
could just issue a certificate for a week or a month and just document the
explanation in the audit (but there are customers needing a solution for the
next several years); or a subCA could be technically constrained or
blacklisted in the untrusted certificate store so that they would be trusted
by the browser. In summary, the poison EKU seems like a good idea.
Ben said we have started working on an amendment that clarifies the scope of
the BRs for auditors as mentioned by Wayne and that we want to make sure
that certain profiles or requirements are met for SSL certificates. We
don't want a party to just leave out the server_auth EKU or do something
else and say that the certificate wasn't intended to be an SSL certificate,
or vice versa. For purposes of answering the question, then, can we say
that there is enough in the BRs currently to make the argument to auditors
that the poison-EKU solution is sufficient to take this out from under the
BRs and that the Forum will modify the Baseline Requirements so that these
types of certificates are clearly out? There was general consensus that
this was the case, and that we also do need to modify the BRs because if a
certificate doesn't comply, then CAs will be failing audits.
9. Issuing test certificates directly off the root: Eddy recalled that this
email question concerned whether test certificates could be issued directly
off the Root CA used to issue EV certificates. Ben read aloud the email
from Bruce Morton a request that we define a set of criteria for test
certificates (issued to the CA's domain, with longer CRL validity periods,
documented processes, etc.). Eddy said that Kathleen has mentioned that
for them it is important for browsers to have the complete certificate chain
for testing purposes. He wondered whether it was a necessity to issue
directly off of a root. So, this should be discussed more. Ben said that
he would draft a follow-up email to Bruce and send it to Eddy for review
before sending it to Bruce that asks questions or expresses concerns about
10. Revisions to the bylaws: Dean said that he had read over the package
with the redlines and changes. Dean thinks that the only thing left is
Section 3.2 on Interested Parties. Ben agreed and said he would tackle it
again. Ben explained that in the definition of "browser" he put in "major
global provider of certificate-using software" even though some might say
the definition is too broad or vague. He was not too concerned because if a
new applicant claims to be a "major global provider of software" we can just
look up how that phrase is used on the Internet - whether the applicant is
listed as "a major global provider of software" because there are not too
many companies recognized at that level. Dean suggested we put all proposed
changes into one document and we can do it all at one time because the
changes to date have not been that controversial.
11. Other Business: Dean said that we had received an application for work
group participation from Aida Travel Port, who would like to join the Code
Signing Working Group. Once we receive clarification on an outstanding
question about the entity signing the IPR Agreement, then they would be
allowed to participate, but activity of the Code Signing Working Group is
already winding down because they are about to approve the working group
draft. Code signing and EV Guidelines working groups are having their calls
12. Next phone call is Thursday, November 7. Again, those observing
Daylight Savings in Europe and North America will call in one hour earlier
because this call is always at 1600 UTC.
13. Meeting adjourned.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5453 bytes
Desc: not available
More information about the Public