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

[Ben Wilson]

Notes of meeting

CAB Forum 

2 May 2013

Version 2

 

1.                   Present:  Steve Roylance, Ryan Koski, Erwann Abalea,
Mads Henriksveen, Atilla Biler, Mert Ozarar, Ben Wilson, Eddie Nigg, Dean
Coclin, Arno Fiedler,  Jeremy Rowley, Wayne Thayer, Joe Kaluzny, Robin
Alden, Gerv Markham, Rich Smith, Stephen Davidson, Phillip Hallam Baker,
Rick Andrews and Geoff Keating

Guests: Andy Regenscheid, Deb Cooley, Mike Jenkins, Mike Boyle, and Jeff
Burke 

 

2.                   Agenda review:  Version 1 of the agenda was reviewed.
Gerv suggested that Item 9 (Mozilla Inclusion Policy and Certificate
Suspension) be stricken from the agenda because it had already been handled
online with discussion between Jeremy and Kathleen. 

 

3.                   Review Reference CP (NIST IR 7294):  Andy explained
that NIST has worked with NSA in an effort to raise the bar for public CAs.
The reference CP is a starting point that will be used to get feedback from
a wider audience.  Work was motivated by security incidents from CAs that
have highlighted the need for stronger security practices.  The audit
programs used in the past have not been strong enough to find the security
weaknesses.  This effort is part of an effort to push for stronger CA
security practices.  He said that we should all be working towards the same
goal.  It is his hope that a well-written set of baseline requirements in
the standard RFC 3647 format will advance CA statements of policies and
practices that will improve audits.   The draft CP was based on input from
CA/B Forum guidelines, audit programs, Federal PKI, NIST documents, the
Canadian government, and PKI industry standards and papers.  The federal PKI
common policy was used as a starting point because it has a strong baseline
that is achievable and it has well-written procedural requirements, trusted
role requirements, key management and certificate lifecycle sections.  It
references the CA/B Forum identity proofing sections.  The reference CP
improves upon the common policy CP by adding more detail to access control,
system integrity, isolation and boundary protection, remote access, and
network monitoring . those are the areas that needed to be addressed based
on the threats we have seen. 

NIST is seeking feedback from CA/B Forum members, U.S. Government PKI, and
other organizations.  It should be recognized that this is just a starting
point for further work.  Our partners should recognize that for this to have
impact, we need to have input so that everyone will see value in the
requirements and so that the CA/B Forum will incorporate these into its own
requirements and so that other industry organizations will integrate this
reference CP into their PKIs.  As you may be aware, there are related
efforts underway ITU-T, ISO, CA/B Forum, etc.  This document is up for
public comment until June 7.  The authors would be happy to go over things
in more detail, but they just wanted to give an overview of what they would
like to achieve.

Question from Ben:  When you were working on it, did you try to accommodate
an international audience?  

Answer:  We are hoping this will be applicable to a broad community.  If
there are things that anyone doesn't feel are appropriate for the
international community, please let us know, give us feedback, and we will
look at that.  

Comment from Stephen:  For outside the US, there are CAs that may be under a
voluntary accreditation scheme in their country where the local regulator
will have a requirement that is similar, but will make the terms more
specific and demand that they be stated in the CP or CPS and be given higher
priority.  If so, when they see a standard originating out of the US, they
are more hesitant to embrace it.

Response:  We all have an interest in having a consolidated set of
requirements to use as a baseline that we can work towards, and we will all
be better off if we can get behind some minimum expectations on the security
controls in place.

Question from Ben:  Are delegated third parties addressed in the reference
CP?  Such as internal CAs, external CAs, or registration authorities? Is
there anything in here about that, or has that not been addressed?  

Answer:  There is an expectation in the reference CP that all requirements
would apply equally to other organizations, like RAs.

Question from Rick:  Would it be helpful to point out certain sections that
are more important for us to focus on in providing our comments, or
highlight those that people should especially look at?

Answer:  The computer lifecycle and network security control sections (5, 6
and 7), the certificate lifecycle sections, section 5 on audit logging,
incident response, and personnel security controls are also places we
changed the most, but we would like to get feedback on the document as a
whole.  The other sections should be looked at carefully as well, for those
of you who are not familiar with the existing federal PKI Common Policy.  

Question from Ben:  Have you thought about creating an annotated or other
type of document to go along with the reference CP, maybe as interpretive
guidance?  Because certificate policy documents are often brief and narrowly
written, and with audit criteria this is often the case.

Comment from Arno:  Yes, with ETSI, the audit guidelines, interpretative
documents, audit scheme, and the education and qualification of the auditors
are very important, sometimes more important than the policy itself. 

Answer:  We agree-the audit scheme is very important.  As we've been working
on this we've been hoping to develop clear requirements for auditing
programs.  In response to the question on annotated format, that's what
we've tried to do.  We've been calling it a reference policy because that is
kind of what it is.  There are sections that are best left to a particular
PKI community to determine for themselves. Some sections have suggested text
or blanks to allow for this.  There are also informational sections to
explain what kind of security we'd like to achieve and what information we'd
like to see in the area of certificate application requirements.

Comment from Jeremy:  We will prepare comments and send them over to NIST
before the deadline.  

Response:  We would be happy to sit down and talk to people individually or
as a subgroup interested in this.

Ben:  Digicert will provide comments, but does everyone want to provide
comments on a unified prospective using a comments matrix.  

Dean:  Does the CA/B Forum want to organize a comment matrix?

Jeremy:  Maybe as a group we could highlight the differences between the BRs
and this document.  Going through there are a lot of things that are
different and it would be interesting for CA/B Forum members to see these,
and we would be interested to hear why certain things were left out and
others were put in, etc.  

Dean:  Vetting and authentication are an example of how this has been left
open.

Jeremy:  But there is discussion of how to handle an individual requesting a
certificate, and the validity periods of certificates are also addressed.  

Deb:  The certificate validity periods are one of those situations where you
would fill in for your particular need.  The guideline for our
recommendation of an appropriate number could be changed. 

Jeremy:  The concern that I have and maybe Kirk has as well is that this
becomes a baseline for what CAs are expected to be doing.  The problem is
how this gets implemented by browser root programs or how CAs may interpret
what they should have to do to comply with it.  If people are free to change
the numbers however you want, then how can it be a baseline.

Andrew:  We've had conversations about how different communities might
implement this, but each community will have to look at the considerations
applicable to them when deciding how they implement this and apply the
appropriate numbers.  The intent is just as guidance, and there is not set
validity period that you should meet.  It is just a Reference CP that people
can use when writing their policies, but it also represents a minimum set of
policies that we feel is appropriate for publicly trusted CAs.   

Stephen:  There is a lot of support across the industry for improving the
security of CAs, but during the process of creating a universal vetting
practice across the industry we realized that it gets pretty tough.   For
example, just one thing that popped up as I leaf through this document is
Section 3.1.3, it says that CAs should not issue pseudonym certificates, but
under many international and European accreditation schemes are allowed, or
may be required for certain uses, as long as the real person is identified
by the CA. 

Deb:  The CP uses the group certificate and the role certificate, rather
than a pseudonymous certificate.  

Stephen said he'd send some information to Ben for the minutes.
Subsequently Stephen sent the following for inclusion in the minutes, "ETSI
TS 101 456, Section 7.3.3, allows "the name of the signatory or a pseudonym
which shall be identified as such", which ties into the EU Data Protection
directive as an option.  The rules are the CA must know the person's real
identity and must divulge to authorities under appropriate
process/circumstance."  Arno also requested the following addition "TS 101
456 from 2007 is only about qualified certificates issued to natural persons
for electronic signatures that are legally equivalent to hand-written
signatures.  A  qualified certificate is a certificate that meets the
requirements of Annex I of Directive 1999/93/EC and is provided by a
certification-service-provider fulfilling the requirements of Annex II of
the Directive.  So EU Data Protection is important to TSPs/CAs wanting to
issue qualified certificates  in Europe.   Also, ETSI and CEN are working
within the EU Mandate/460 to develop a new set of standards for the prosed
EU EIDAS Regulation."

Andy:  We really hope to influence change in the sector, but NIST is not a
regulatory authority, and we cannot effectuate change on our own.  Please
look at it and give feedback on where it doesn't go far enough or goes too
far, and we hope you find this valuable and will provide feedback as
appropriate.

4.                   Approve Minutes of 18 April 2013:  Approved as
published.

 

5.                   Review of Ballots:  Ballot 99 closes on Friday,
3-May-2013.  Rick stated that he received comments and questions from Tom on
the Guidelines for EV processing, but that he hasn't had time to look at
those yet.  Atilla said that they had voted in favor of Ballot 99, but they
did not see that vote come across on the public list.  Ben said that we can
confirm that vote offline via direct email.  On the OCSP responder concern,
Joe said that he is concerned and surprised that Microsoft does not have
plans to revise their product to prevent OCSP "good" responses for
non-issued certificates.  Stephen said that CoreStreet responders might have
trouble, too.  Joe said he was surprised that more CAs were not alarmed and
that he will either need to look at switching to another solution, which
will take time, or change the Baseline Requirements, depending on how many
vendors are supporting the change.  Phillip said that CoreStreet
(HID/ActiveIdentity) and any other company that wants to remain in this
business should support a mandated feature.   It may be that Microsoft
developers responsible for this product segment are not aware of this
requirement or they lack incentive to change this functionality because it
comes "free", as part of Microsoft's CA product.  

 

Stephen D. said that some CAs were uneasy about putting a hard deadline on
this when it was adopted because it was an external dependency on whether it
would be supported.  The August deadline might be easy for CAs who have
developed their own OCSP responders internally, but it is difficult for CAs
who depend on off-the-shelf solutions.  Arno said that it may be difficult
for CAs in Europe where this non-compliance might be found as a security
violation.  Stephen said that a similar issue exists with Certificate
Transparency for smaller CAs relying on their off-the-shelf infrastructure.
Joe suggested that the OCSP provision might be modified to a "should" rather
than a "must" because he cannot meet the August date, or the CA/B Forum
needs to make a definitive statement that the requirement will not be
modified.  Steve R. said that he was in discussions with Microsoft on the
EKU problem and would raise this issue, too.  Phillip said that it is one
thing to slip the date, but we shouldn't relieve vendors from the pressure
to get their product up to spec.   Otherwise, we'll come back in a year and
none of them will have done anything to fix their product.  Stephen said we
ought to look at OCSP responder behavior, just like the IETF WPKOPS project
on client behavior is looking at clients.

 

Rick noted that yesterday he had sent around an email from CoreStreet that
indicated they had a workaround called Smart Data Bridge, but that users of
that product would have to evaluate for themselves whether it would be in
compliance with the BRs.   Steve R. said that we may have lost 18 months by
not moving forward better on this with the vendors of software products like
Microsoft and Entrust.

 

6.                   Other Announcements - Date Change for Ankara F2F
(September 24-26); recent ITU Actions:  Ben announced that it looked like
the Ankara F2F meeting would be held on September 24-26 based on the
comments that had been received.  With ITU, it appears that there have been
efforts to revise X.509.  Copies of the documents are being circulated for
review.  The concern is that with the ITU the group perpetuates with
involvement from too few participants in industry implementing the standard.
The other problem also is that there are national debates going on as well. 

 

7.                   NFC Forum proposal to revise Signature Record Type
Definition - Technical Specification (NFCForum-TS-Signature_RTD-1.0):
Jeremy announced that Tony Rosati of Blackberry/RIM and the NFC Forum wanted
to know whether CAs were interested in developing policy similar to EV Code
Signing and issuing certificates that would be used to support digitally
signed RFID tags that would have a very long validity period.  Any CA
interested in getting involved in reviewing draft policies and working on
this should contact Jeremy.

 

8.                   Continued discussion of audit requirements / technical
constraints for external subCAs:  Steve R. said that as part of the
technical constraints issue he has been discussing the EKU for OCSP signing
with Microsoft.  The EKU for OCSP signing would need to be present for
certain CAs and sub-CAs.   He does not have solid feedback needed to resolve
the issue, but by sometime next week he hopes to have edits to the current
draft on his ballot to address Name Constraints, Auditing and EKUs.  

Steve provided an overview of the issues.  First, there is an open issue on
how the audit requirements flow down to third parties when technical
constraints like name constraints are available for sub CAs.  If we are able
to clarify how browsers will treat these then we have alternative ways for
growing the use of PKI with an expanded CA hierarchy.  One option is to hold
a straw poll to determine whether the Baseline Requirements apply to
everybody in the system or whether there are possible exceptions.  

Dean expressed concern that Apple does not enforce the critical name
constraints policy, and if we allow this exception for 10% of the ecosystem,
then how is that 10% protected?  Steve said that it is a chicken-and-egg
problem - how will Apple implement it if no CAs are implementing it?  If
auditing is mandated, then it just becomes too expensive, so implementing
name constraints is a better, more cost-effective alternative.  Similar to
the CoreStreet example earlier, we need to make sure that name constraints
are clearly written in the requirements so that they can be used in
different architectures, including such things as signing certificates and
other solutions beyond what we're talking about today.

Rick said that we need to define how name constraints should work, because
even across browsers today it is clear that there is disagreement on how
they should work.  Steve noted that the use of directory names as a minimum
standard, as discussed on the mailing list, is an example of how tying this
down will allow us to grow name constraints for client certificates and
other uses and models.  At some point we'll be able to switch over from
non-critical to critical, but we'll need to get that 10% support from Apple,
but they're not going to do it unless we're actually using them and relying
on them.  Rick said that as Dean asked, is it unsafe to use them until we
have better understanding and agreement across all browsers on (a) using
them and (b) how to use them?  

Steve said that the unsafe alternative is not to use them and instead rely
on auditing, which is completely open so that if you are attacked the whole
world is exposed, but if you use name constraints the attack surface is
smaller--you can only attack the browsers that don't support them or the
domain name in that certificate, so I'm a proponent of name constraints and
to make them critical because as has been shown in the past you can't rely
on audits.  Dean said you could do a combination of both name constraints
and audits until all browsers support name constraints. Steve said that he
has that internal audits continue in Section 17, which CAs are going to be
concerned with, which will tie into the OCSP responders as well, because we
need to make sure that the database saves OCSP responses, and that will all
tie in nicely, but if we mandate audit and name constraints, will only
discourage people from using PKI, which is not what we want.   

Rick said that he disagreed with Steve's statement that anyone using name
constraints can only shoot themself in the foot.  For example, if there is a
constraint on DNS names, but no constraints on IP addresses, some browsers
will obviously constrain DNS names, but then browsers are inconsistent with
what that means for IP addresses.  Some browsers will interpret that to mean
the certificate cannot sign anything for an IP address, while others will
interpret it to mean that IP addresses are not restricted, so that leaves IP
addresses open to attack.  Those subCAs can shoot anyone else in the foot,
as long as they don't violate the specified name constraint.

Steve said that particular issue was included in the Mozilla inclusion
policy, which I've included in the wording-permitted and excluded, so IP
addresses are mandated to be taken out, so you don't have that issue, and
all browsers should be moving that direction.  Audits help you close the
holes, but they do not help you reduce the attack surface.  

Rick said that while Internet Explorer, Chrome, and Firefox might implement
name constraints in some form, we do not know whether they allow issuance of
IP address certificates when there is only a name constraint.  Steve said
that IP addresses are not currently the major means of attack, it is the
*.google.com certificate that is an issue.  Rick said that there may be more
scenarios beyond the IP address example, given the confusion around
interpretation of name constraints.  

Ben said he believed that the US Government and DOD seem to know how to
implement name constraints, and they must have browser validation criteria
they use to test, for instance, whether Safari meets the processing
requirements.  Dean suggested that this issue be at the top of the agenda
during the meeting in Munich.  Steve said that he would have some materials
ready to review prior to the F2F meeting, but he would like to tie down
Microsoft on this issue first.  

Dean said he and Rick just want to know how we're improving the security of
the ecosystem.  Steve said that by deploying more PKI for enterprises using
client certificates with Microsoft CAs instead of usernames and passwords
we're enabling better enterprise security that is needed with the growing
use of mobile devices, etc.  As we've discussed in Tokyo and Paris we cannot
audit everyone, so we need to find better technical constraints that work to
reduce risk.   So with name constraints we need to convince Apple to close
that gap.   Stephen Davidson seconded Steve Roylance's comments.

9.                   Any Other Business:  Dean said that 28 people from 10
different countries have signed up to attend the F2F meeting in Munich.
Anyone who has not registered yet should do so as soon as possible because
we are almost out of rooms.  

 

Next Code Signing meeting will be next Wednesday, May 8, at 1600 UTC, this
time using the same CABF dial-in number as for this call.

10.          Next CAB Forum call will be Thursday, May 16, at 1600 UTC.

Meeting adjourned.

 

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