[cabfpub] Notes of meeting - CAB Forum - 16 May 2013 - Version 1

[Ben Wilson]

Notes of meeting - CAB Forum - 16 May 2013 - Version 1

 

1.             Roll Call:  Ben Wilson, Rich Smith, Wayne Thayer, Mads
Henriksveen, Rick Andrews, Dean Coclin, Geoff Keating, Eddy Nigg, Simon
Labrum, Atsushi Inaba, Arno Fiedler, Jeremy Rowley, Ryan Koski, Tom
Albertson, Atilla Biler, Robin Alden, Philip Hallam Baker, Ryan Sleevi 

 

2.             Agenda Review:  Agenda was reviewed.

 

3.             Approval of the Minutes of 2 May 2013:  It was noted that
Geoff and Mert were in attendance; Arno said he would like to submit
additional information about ETSI policy, qualified certificates, and EU
data protection for the minutes.  Minutes of 2 May 2013 were approved,
subject to review after those changes.

 

4.             Ballots:  None pending. 

 

5.             News - Recent Netcraft post:    Rick said that he wanted to
bring this to everyone's attention in case we are asked questions about it.
Ben said he had read through Netcraft's post and regarding the 12-month
validity of an intermediate CA's CRL, it could be shortened in some browsers
by changing the default settings to re-check for updated CRLs more
frequently.  Jeremy said the Baseline Requirements require revocation and
new CRL  issuance within 24 hours.  Ben said one of the problems mentioned
was that the CRL had been encoded differently, and he wanted to understand
this issue better.  Ryan Sleevi said that all browsers in their default
configurations will treat the nextUpdate as the caching period, so assuming
no other variables, they won't be checking for CRL updates.  He also
explained that Chrome and Firefox use NSS for revocation checking.  He has
seen that some CAs take the DER-encoding of the ASN.1 structure and then
encode it to Base64/PEM, while most implementations follow the standards,
which require binary DER encoding of CRLs in binary octets.  Sometimes this
CA practice may be attributed to the fact that non-binary works in Internet
Explorer, so there is the wrong assumption that it works elsewhere.  Rick
suggested that we add a requirement to the Baseline Requirements that CRLs
be published in DER format.  Ryan S. also said that negative serial numbers
also are problem.  Rick said that not only should we reach out to CAs on
this, but we also should address what browsers are doing about revocation,
because the article said that Firefox wasn't checking the CRL at all, and we
should be prepared to provide feedback on that issue as well.

 

Ryan S. said that there has been discussion on the Mozilla list about
eliminating the preloading of CRLs that it does fetch and that Firefox has
relied primarily on OCSP and not CRL fetching for some time.

  

Rick asked whether IE and Opera hard fail.  Ryan S. said they actually soft
fail because if you clear the caches and they download the CRL, then they
would block access.  However, blocking the download of the new CRL
effectively defeats this because IE and Opera would continue allowing access
to the site (i.e. no hard fail).  Rick said that even if it doesn't help
with that security attack, it is a hole that should still be plugged because
if you downloaded the CRL you could still block access to the site. 

 

Tom said that his takeaway from the Netcraft article was that using CRLs
with a long validity period provides little value.  Eddy responded that the
issue was discussed quite a bit with the Baseline Requirements and the
problem with issuing more frequent CRLs was that the root key would have to
be taken out every time to sign the CRL, and every time you take out the
root, there are some risks.  That was the reason why it was decided upon as
one year.  Tom said he was not recommending touching roots every day, but
that he would like to continue a discussion of these issues during the
face-to-face meeting in Munich, including the process of adding revoked
intermediate CAs to the Disallowed Certificates in the Microsoft CTL.

 

6.  Discuss errata proposals and ballot drafts - Domain Validation Change
Proposal:  Rich said he feels that the proposal sent out by Jeremy yesterday
has most of the problems worked out.  Most language from the EV guidelines
has been left in, but the proposal would allow additional BR techniques in
section 11.2.6 where the applicant is not the registered owner of the
domain.  Jeremy said that the proposal basically allows two additional
methods for control of a domain without a letter, and the requirement would
still be to check the WHOIS records first, but if the applicant did not have
the right information available through WHOIS, you could still validate the
domain by other methods.   The plan would be to get feedback now before it
goes up to ballot so if anything needs to be changed, that we can resolve
concerns.  The proposal also follows Mozilla's recommended practices for
verifying domains.  Eddy asked what the browsers might think of the proposal
before we go forward with it.

 

Tom said it is mainly up to the members of the CAB Forum to decide and
Microsoft did not have a position unless it affected code, processing,
browser operations, etc.  Geoff said he looked at the recent edits and that
he still had concerns because it seemed to be the same thing re-edited-it
proposes to remove "exclusive" and that the applicant knows about the
certificate request, etc.   Jeremy said that the latter part has been left
in Section 11.2.6(3).  Rich said that the "exclusive right to use" language
has never been fully understood, and that is why we should take it out.
Geoff asked whether the "exclusive right" caused problems.  Jeremy said it
does because it requires people to get attorney letters.  Eddy asked what
was wrong with WHOIS and you don't need an attorney.  Jeremy said that the
WHOIS records are sometimes difficult to rely upon because of delays in
updating them, etc.  Eddy disagreed that WHOIS was difficult to update.
Jeremy said many people don't have access to update WHOIS, even though a
party has control, but the information isn't accurate.  Eddy said that it
was a problem in itself.  Jeremy said another example is the subdomain where
an applicant doesn't really have direct control of the domain registration
information but does have control of the subdomain, like the chemistry
department at a university.  Eddy said he didn't believe that the Baseline
Requirements allowed validation in that situation.  Rich said the BRs do
allow it under the 5 types of domain administration email addresses there is
an option to create email addresses by pruning zero or more components from
the requested FQDN.  Ben noted that in the attorney opinion letter template
at the end of the EV Guidelines it also mentions "exclusive control" and
that some attorneys have crossed exclusive out when it is a subdomain. 

 

6.  Discuss errata proposals and ballot drafts -DC Naming Proposal:  Ben
said that Steve Roylance wanted to conduct further review of the proposal to
modify the language concerning DC naming because he thought it might break
something that GlobalSign was considering as a technical mechanism for
controlling sub CAs through critical domain name constraints and would we
also need to look at any RFC 5280 issues.  Jeremy said that he had
circulated some examples of what is being done in the Grid community and a
proposed ballot as well.  He said that the Grid community has
well-established precedence in how they are implementing DC naming and that
our language in the BRs should not override their precedent.  The grid
requirements have also been circulated for everyone to review.  Ben asked
what the plan should be.  Jeremy said that there is an immediate need to
revise the BRs so that publicly trusted Grid certificates are considered
compliant and that issues raised by Steve R. could be reconciled later.
Robin said that he supported the concern and ballot.  Ryan S. said that
since we are talking about domains we should understand the issue more, but
it sounds like this is similar to the approach that has been taken with the
OU field and verified vs. non-verified information.  Ben suggested that an
explanatory preface be added to the proposed ballot.  Jeremy said he would
take a look at the language and tweak it.  .

 

7.  Attorney/Accountant Jurisdictions:  Ryan K. noted that the definitions
section for accounting practitioner talks about "country" rather than just
"jurisdiction", but then section 11.10.2 for accountant it has to be in the
jurisdiction, which seems to be an oversight/errata because in the section
for legal practitioner/attorney, "in the country of" is still in there.   He
said that when he raised this last January, Kirk and Don Sheehy both weighed
in to discuss state-to- state jurisdictional issues for accounting
professionals, etc.  Ben said he understood the issue and it shouldn't be
any different between accountants and attorneys in the same country, so he
would support putting the word "country" back in.  Ben will work on an
errata motion to fix it and other similar typos that we've found in the BRs
and EV Guidelines.  

 

8.  IPR Policy:  Ben said that he had circulated a draft IPR Policy
Agreement for Interested Parties and asked whether members could send it to
their attorneys to take a look at.  Tom said he forwarded it to Microsoft's
attorney, but there has been no time yet for a response.  He asked whether
Ben had forwarded it to the CABF IPR legal committee and he said he hadn't
but he would do that right away.  Tom also expressed concern that this IPR
is a subset of the CABF IPR - "Why do we need an IPR that appears to bind
people to the subset?"  Ben said he would expect the IPR legal review
committee to discuss that issue. 

 

9.  Update - Code signing working group:  Jeremy said that the WG had met
last week and the meeting went well.  They are working on verification
requirements and key storage requirements.  The general consensus is that
identity vetting would be similar to what is required for OV, but they are
looking for something else for key storage that is secure.  Jeremy is
working on a draft and hopes to have it done for next week's call.  Dean
said he expects that we'll be able to get everything ironed out in Munich.
He also noted that a new member has joined the CA Browser Forum from the
Czech Republic, and also another member request came in from someone in
Germany.

 

9.  Update - NFC Forum:  Jeremy explained that the RFID industry is looking
for a way to sign RFID tags.  He asked whether we should have a working
group inside or outside of the CAB Forum.  One issue is that the NFC Forum
has its own IPR Policy.  Someone here would have to look at it and make sure
it's OK.  Then we could sign an MOU and the relationship would be similar to
CABF with ETSI.  Jeremy asked if anyone was interested.  Rick and Wayne said
there might be sufficient interest within the CAB Forum to work on it, but
if it becomes a battle over IP policies, then it's not worth it.   The group
briefly discussed the advantages/reasons for working on this in the CA
Browser Forum as opposed to another group.  Jeremy noted that the documents
are really about vetting and the processes would be very similar to EV Code
Signing.  Jeremy noted that most mobile browsers are part of the NFC Forum,
and Ben noted that mobile browsers are becoming more important to the CA
Browser Forum.  There was discussion that we might or might not have all of
the right players here, but so far we have enough to get started and the
right documents.  Wayne suggested that we might put the proposal for an MOU
with the NFC Forum out on the list and see if anyone objects.  If so, then
those interested can go another way about it separate from the CAB Forum.

 

10.    Agenda planning for Munich:  Ben said that he and Dean will get
together and put up a rough agenda on the wiki.  Dean said that even more
people have signed up to attend.  

 

11.  Next call:  May 30.

 

12.  Meeting adjourned.

 

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