[cabfpub] Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28 June 2012

Wed Jul 11 13:16:19 UTC 2012

Hi Inigo,

On what basis did you say that “European Web sites would be required to have
a qualified certificate” ?

I agree that the regulation would allow UK TSPs to claim that they issue
‘Qualified website certificates’ and they would have to meet the same
standards as any such providers based in other Member States. That is not
the same as saying that commercial providers/users must use such products.

As always it is likely to be the commercial imperative of recognition by
browser trust stores that will drive adoption not legislation – at least in
the UK, I can’t answer for Spain etc.

Best regards

Richard

------------------------------------
Richard Trevorah
Technical Manager
tScheme Limited

M: +44 (0) 781 809 4728
F: +44 (0) 870 005 6311

http://www.tscheme.org
------------------------------------

The information in this message and, if present, any attachments are
intended solely for the attention and use of the named addressee(s). The
content of this e-mail and its attachments is confidential and may be
legally privileged. Unless otherwise stated, any use or disclosure is
unauthorised and may be unlawful.

If you are not the intended recipient, please delete the message and any
attachments and notify the sender as soon as practicable

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Tim Moses
Sent: 04 July 2012 17:19
To: CABFPub
Subject: [cabfpub] Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28
June 2012

Notes of meeting

CA/Browser Forum

Gjøvik, Norway

26-28 June 2012

1. Introductions

Tim Moses, Don Sheehy, David Rockvam, Bruce Morton, Ryan Koski, John
Johansen, Mads Henriksveen, Sissel Hoel, Simon Labramm, Jens Bender, Kerstin
Schönherr, Rick Andrews, Ben Wilson, Jon Callas, Kirk Hall, Gerv Markham,
Arno Fiedler, Robin Alden, Moudrick Dadashov, Tom Albertson, Dean Coclin,
Yngve Pettersen, Inigo Barreira, Jeremy Rowley, Brad Hill, Håvard Mollard

        Bruce read the anti-trust statement.

2. In the news

Yngve said that Opera 12 has been released, with some certificate-related
updates.  He brought up renewed concerns about the security of MD5 resulting
from the "Flame" incident.

Gerv said that CNNIC has applied to have its root included.  He said that it
is already included in Windows and Opera.  Rick asked whether it would make
sense to (for instance) remove Chinese CAs from the list of CAs trusted by
default by US users.  Gerv said that the idea of localized trust-stores has
been consider.  But, problems exist.  He thought that CA-pinning would
provide a better solution.  Jens mentioned problems with pinning, such as
the "initial trust" problem, key roll-over and multiple certificates per
domain.  Gerv said that "large-scale surveillance" helps with the initial
trust problem.

Brad said that the installed OS language pack could determine which CAs to
trust by default.  Gerv said that some portion of users would be adversely
affected.  And some CAs need to be able to operate in multiple regions.

Tom said that Microsoft has merged its root programs for Windows and Windows
Phone.

Microsoft has introduced an accelerated CA-disablement mechanism that will
allow them to disable a CA within 24 hours.  It is effective for both roots
and Sub-CAs.  They are hesitant to extend the mechanism to end-entity
certificates.

Microsoft will stop accepting RSA keys shorter than 1024-bits in August.
There will be an exception for keys of length 1023-bits.

Robin said that CAA has passed working group last-call.  However, BR v1.1
will be ratified too soon to incorporate CAA.

Yngve said that Apple has upgraded iOS to require 1024-bits.  Gerv said that
Mozilla is likely to do the same.  Yngve mentioned that IBAN still uses a
768-bit ciphersuite.

Rick mentioned that the DANE RFC has been ratified.  He is concerned that
browsers may grant self-signed certificates the same UI treatment as TTP
certificates.  Gerv said that Mozilla may consider a DANE key as equivalent
to a DV certificate.  Tim pointed out that this would mean that DANE keys
would be rated equivalently to an OV certificate.

Kirk asked if Mozilla would require DNSSEC operators to submit to audit.
Brad pointed out that DV certificates are just as reliant on correct
operation of DNS as DANE is.

Rick suggested preparing a profile of DANE that leveraged TTP certificates,
and he asked for interested CAs to contact him.

Tom said that (some time ago) he had had contact with DANE proponents.  He
had explained to them Microsoft's key-reliance assurance requirements.  The
proponents did not consider those requirements appropriate to DANE.  Tom
said that he couldn't predict how browsers would treat DANE keys.

3. WebTrust

Don said that WebTrust for CAs v2.0 will come into force on 1 July 2012.
The task force has developed an exposure draft for the Baseline
Requirements.  It is proposed that an audit covering Baseline Requirements
will result in a report separate from the WebTrust for CAs report.

The task force will meet sometime in the last two weeks of July to address
comments received from CICA and AICPA on the exposure draft.  They expect to
have a functional version by September 2012.  At that point it will be
practical for root programs to require BR compliance.  But, audit to these
criteria will require the CA to have operated in accordance with the
Baseline Requirements for the duration of the audit period.  Network
security requirements will be addressed in a future version.

Gerv said that an audit letter should indicate which version of the criteria
were used in the evaluation.

Don said that WebTust for CAs v2.0 is organized in accordance with ISO21188.
He said that some WebTrust clients don't issue publicly-trusted
certificates, so WebTrust for CAs cannot be replaced by the Baseline
Requirements criteria.  However, the task force is considering combining the
two criteria in a single document.

Don said that the Network Security Requirements are now in a condition that
is much more suitable for auditing purposes.  They will ultimately be
incorporating into WebTrust for CAs v2.1.  Inigo said that ETSI is
monitoring the Network Security Requirements project.

Don thanked Ben for his assistance in the development of the network secure
criteria.

4. ETSI

Arno made a presentation on TS 102 042 v2.1.1 that was issued in Dec 2011.
It will become a European Norm.  ETSI is also working on TR 101 564 that was
issued in September 2011, containing guidance to auditors when conducting EV
audits.

TS 119 403 v1.1.1 (issued in March 2012) defines qualification requirements
for auditors.

Each European country has its own scheme for managing audits and accrediting
auditors.  National accreditation bodies are listed under “European
Co-operation for Accreditation”.  And qualified TSPs are listed in the Trust
Service Status List.  The list is a signed XML document.

Tom observed that the list does not indicate against which standard the
conformance was assessed.  Inigo said that it would depend upon the country;
but all are “qualified”.  Arno said that this deficiency is recognized.
Jens said that the list relates to qualified signatures, and (by law) all
such signatures are considered equivalent.  But, the same cannot be said of
SSL certificates.

Arno said that TS 102 042 v2.3.1 incorporates the Forum’s Baseline
Requirements.  There is a corresponding TR being prepared.  It will be
practical to conduct a v2.3.1 audit by October 2012.

Arno reported on new regulations that are being prepared to replace the
Electronic Signature Directive.  Unlike the original directive, the new
regulation will SUPERSEDE national legislation.  It would require clear
supervision of TSPs and require annual audit.  It will also introduce
“qualified” Web server certificates.

Arno mentioned plans to hold another CA Day in Berlin on 28 and 29 November
2012.  He offered the possibility of a joint meeting with CABForum.

Inigo mentioned that a draft of the new regulation has been published:-

<http://ec.europa.eu/information_society/policy/esignature/eu_legislation/re
gulation/index_en.htm>
http://ec.europa.eu/information_society/policy/esignature/eu_legislation/reg
ulation/index_en.htm

It talks about Trust Service Providers, rather than CAs.  It covers person
signatures, Web-servers, time-stamps, and email.  It defines electronic
seals and advanced electronic seals.

The regulation admits TSPs from non-member countries.  Apparently, Adobe is
considering using the EU trust list instead of managing its own root store.

Inigo was asked if European Web sites would be required to have a qualified
certificate; he said yes.  However, Jens said that he read the regulation
differently.  Qualified certificates will be identifiable by a policy
identifier; a certificate that claims to be qualified must be qualified.

It is hoped that the regulation will come into effect on or before 2014.

5. BSI (Germany’s Federal Office for Information Security)

Jens presented on the BSI’s plans in relation to Web server certificates.
He noted a shift in attack strategy away from individual targets towards
infrastructure targets.

He discussed the Diginotar incident and noted that Diginotar was considered
trusted on the basis of a PWC audit to ETSI standards.  Diginotar also
posted a false WebTrust seal on account of a qualified EV audit report (also
conducted by PWC).  The ETSI audit discovered no major invalidities.  Jens
noted that some mobile devices still trust the Diginotar root.

Jens said that Diginotar suffered well-understood IT security flaws.  And
the audit didn’t work as expected.  The audit should cover network
architecture.  The flaws should have been uncovered in both the ETSI and
WebTrust audits.

He concluded that the SSL PKI can only work if it is seen to be trustworthy.
So, we need to rebuild trust in the SSL PKI.  As part of this we need a
trustworthy audit process.  But, currently, there is no comparability
between audits.  Penetration testing should be part of the framework.  And,
there should be a common base of security regardless of the application
(Web, email, etc.).

Germany is working on requirements, based on ISO 27001 and common criteria.
There will be generic requirements for all CAs and “building blocks’ per
application.  They plan to impose the requirements wherever they can and
promote them in other countries.

6. Governance

Jeremy noted that there are currently five proposals.  One of the goals for
governance reform is increased transparency.  Gerv said that he is preparing
a clearer proposal on transparency that he will bring forward for ballot.

Jeremy pointed out the major axes upon which the proposals differ.  These
are: broad versus narrow scope; Division into working groups versus not; IPR
committed at the WG level versus Forum level; and voting limited to CAs and
browsers versus including other interested parties.

Jeremy suggested a straw poll to choose one proposal for a ratification
ballot.

Brad said that the revocation topic is an example of a topic that fits the
broader scope definition.

There was some discussion of a suitable procedure for selecting amongst
three or more options.  Kirk moved that we conduct a series of elimination
ballots.  But, no one endorsed the motion.

Tim made the following motion and Gerv and Ben endorsed it.

--- MOTION BEGINS ---

The Forum instructs the chair as follows:

1. Arrange for the proposals developed by the Governance Reform Working
Group to be posted on the Forum's public Web site.

2. As soon as it appears that the membership set will be stable for the
duration of steps 3-7 (below), announce a ballot with the following steps.

3. A 7-day review period.

4. A 7-day voting period.

5. An instant run-off ballot to eliminate all but two of the proposals; "no
change" is to be included as one of the choices.

6. A two week period during which the authors of the two remaining proposals
may modify their proposals while keeping to the spirit of the proposal that
he or she posted in step 1 (above).

7. Announce a simple-majority ballot to select between the two remaining
proposals, comprising a 7-day review period and a 7-day voting period.

8. A period of undefined duration during which the author of the successful
proposal shall refine the proposal in order to ensure its completeness,
while keeping within the spirit of the proposal that he or she posted in
step 1 (above).

9. A ballot conducted in accordance with established Forum procedures to
ratify the proposal that emerged from step 8 (above).

Note: The instant run-off ballot shall be conducted as follows.

Where there are 'n' initial proposals, each voting member may assign the
numbers 1 to n to the proposals in order of preference (1 indicating their
most preferred choice).  Each member who votes shall (at least) assign the
number '1', and may assign further numbers up to and including 'n'.

Votes ranked '1' shall be counted and the proposal with the fewest votes
shall be eliminated.  The votes of the corresponding members shall be
reassigned to the proposal ranked '2' by those members.  Where a member has
not identified a proposal with rank '2', his or her vote shall not be
reassigned.

This procedure shall be repeated, counting reassigned votes, until just two
proposals remain.

--- MOTION ENDS ---

The results were as follows:

Yes: DigiCert, Izenpe, Opera, Entrust, Symantec, Microsoft, SSC, Comodo,
Mozilla, Go Daddy, Trend Micro, GlobalSign, BuyPass.

No: none.

Abstain: none.

Result: approved.

7. IPR

Jeremy provided a summary of the situation.  25 of the 50 existing members
have entered into the agreement.  Some others said that they would sign, but
they require more time.  The most contentious issue is RAND versus RANDZ.

He listed some issues with the policy:

                It is unclear whether blanket exclusions are acceptable;

                Different approaches are needed for applications and issued
patents;

                We need to clarify whether and how the policy applies to
observers;

                We need to clarify how the provisions apply to acquiring
entities; 

                We need to clarify how the provisions apply to affiliates;
and

                The treatment of new members could be considered a restraint
on trade.

Jeremy said that, if we are determined to overturn the recent emergency
ballot, then we need to ballot a new motion by 18 July.

Revisions to the policy have been proposed by both Jeremy and Jon.  Jon’s
proposal emphasized “disclosure”.

Gerv raised the question of revising the existing policy versus starting
from scratch.  Tom said that revisions have to be considered by the IPR
working group.

Yngve said that an inventor should be required to explain how their patent
applies to the Forum’s work product.  Ben said that this is not realistic.

Gerv suggested that we handle each proposed change in isolation in order to
gauge the extent of its impact.  Tom also suggested that each change
proposal be accompanied by an explanation.

Kirk suggested that a “covenant not to sue” would be preferable to the
existing obligation.

Arno said that ETSI has standard clauses to deal with these issues.

Jon said that it would be practical to adapt the existing policy.  He
thought that the treatment of affiliates and blanket exclusion were the main
problems.

Kirk said that the onus for action should be on the IP holder, not on
members as a whole.

It was generally agreed that observers should be subject to a very
lightweight process; we should not erect barriers to receiving input from
other experts.

Jeremy said that the treatment of new members was likely an oversight.  Tom
said that he thought it was intentional.  Jon said that the fact that a
review period is specified suggests that it is an oversight.

Ben said that members should not be allowed to avoid the provisions of the
policy by creating an IP holding company.

Jeremy proposed that we reconstitute the IP working group and instruct it to
propose minimum changes to accommodate hold-outs.  This was agreed.

Gerv asked whether we should abandon the existing policy or leave it in
place while revisions are considered.  Ben suggested that we extend the
deadline for signing the agreement to 1 Jan 2013.  Jon argued that the
policy be suspended until such time as revisions have been agreed.

It was agreed that the existing policy would come into force on 1 Aug and
the IP working group would be asked to propose minimum revisions to
accommodate Entrust’s concerns.  Entrust would be invited to participate in
those discussions even though its membership will lapse on 1 Aug.

Tim was asked to send email to all current members who have not entered into
the agreement pointing out that their membership will lapse on 1 Aug.

8. BR Issues list.

Issue 1.  Gerv said that Kathleen Wilson has been conducting a discussion,
but a clear answer has yet to emerge.  Tom said that v1.1 should not be held
up as a result.

Issue 5.  Yngve said that he is still working this issue within PKIX.  A
“Revoked” response would have to be signed.  And, we need to avoid the need
for real-time signing.

Rick said that we should consider demanding changes in browser behaviour.

It was decided to disallow the “Good” response in the case where the OCSP
responder for a particular CA does not know if that CA issued the
certificate.

Inigo said that we should seek clarification from PKIX on the use of
certificate suspension.

Issue 6.  Yngve said that his email of 20 June contains a proposal.  Some
further refinement is required.  It was decided that proposals should be
documented in the issues list.

Issue 7.  Rick said that some customers demand smaller certificates.  Gerv
said that CAs should be given discretion in this regard.  So, it shouldn’t
be a “MUST”.  Perhaps this issue should be balloted separately.

Issue 8.  Ryan argued that revoking a subCA requires more time.  Gerv
suggested that we only specify a requirement for end-entity certificates.
Bruce agreed to champion a new issue related to revocation of subCAs.

Issue 10.  Yngve said that this is addressed in his proposal.  Rick said
that we should seek the guidance of cryptographers.  Yngve said that he
would look for guidance from NIST.

Issue 14.  It was agreed to disallow individual names in the CN attribute.
With that modification, the ballot is ready to proceed.

Issue 15.  Bruce said that he combined this issue with a later one and made
a proposal.  Brad said that CAs should be required to revoke a certificate
when its private subject TLD becomes public.

Brad suggested that CABForum consider lodging objections to commonly-used
TLDs.  Gerv said that ICANN should reserve TLDs that already in common use.

CAs were asked to analyze their current certificates for TLDs that will
become public.  Rick offered to consolidate the results.  Brad said that (in
case CAs are concerned about disclosing to Symantec) he would be willing to
do the consolidation.

Brad said that CAs should start notifying affected customers immediately.

Issue 16.  Has been superseded.

Issue 17.  The proposal was in Ballot 78, which was approved.

Issue 18.  This will not be advanced in v1.1.

Issue 20.  Withdrawn.

Issue 23.  Mozilla has an exception on the topic of qualified audits.
Microsoft is removing its allowance of ISO21188.  Apple disallows it.

Robin asked that his name be removed from the issue.  Jeremy agreed to take
leadership of the issue.

Issue 24.  Jeremy said that the wording could be clearer.  He will suggest a
revision.

Issue 30.  The issue is resolved and can be included in an upcoming ballot.

9. Qualified CSPs

Tom said that this is not an issue today, as Qualified CSPs do not
necessarily issue SSL certificates.  Jens agreed; today, SSL certificates
are not qualified.  Tom said that he would be meeting with Stephane Santeson
in July to discuss the implications of the BRs for Qualified CSPs.

10. Network Security Controls

Ben walked through the current draft.  Changes were made and agreed.

In the case of password management, it was agreed to identify and refer to
an existing standard.

It is understood that these requirements will be implemented as part of the
WebTrust and ETSI processes.

It was agreed to go to ballot with a motion along the lines of the BR v1.0
motion.

11. Revocation

Rick went through the current draft.  It recommends adherence to RFC 5019
over RFC 2560.  It recommends using GET as opposed to POST.  The client
could fall back to POST in case GET is not supported by the server.  There
were some questions over what error would be returned in this case.

Some performance results are available.

Rick said that it is important to achieve consistent behaviour amongst OCSP
clients.

The document recommends support for stapling.

Yngve said that Opera does not cache OCSP responses, but it does request
session-resume.

Ryan said that Go Daddy OCSP responses are valid for six hours and are
updated every three hours.

There was some discussion of the size of OCSP responses and how they might
drive over a packet boundary.

Yngve suggested that there should be a companion document with
recommendations for Web servers, addressing (amongst other things) session
resumption.  A significant number of servers don’t support this feature.
Session resumption may depend on shared state across a back-end network or a
session ticket cookie.  Ryan said that the former would be rare.  Load
balancers may ensure that clients continue to be served by the same server.

Ryan asked about the purpose of the project.  Gerv said that there is value
in a “best practices” statement from the Forum to help prioritize Mozilla’s
development program.  Yngve agreed.

Robin pointed out that a client may have good connectivity to a Web-server,
but poor connectivity to the CA’s OCSP responder.

Some felt that Google’s CRL Set solution may not be suitable for all
browsers.

Tom said that Microsoft’s new “disallowed CTL” is not meant to replace CA
revocation schemes.

There appeared to be broad agreement that stapling is the best solution.
Nevertheless, there is value in recording other recommendations (such as
retry and preference for GET).

Yngve raised the question of how long a certificate should be relied upon
when an OCSP response cannot be obtained.

There was also some discussion concerning client support for multiple URIs,
which is offered in Windows, but not in other clients.

Robin mentioned the “must staple” proposal.  But, it was acknowledged that
this only defends against certain attack vectors.

Ryan raised the question of revocation for subCAs and the long validity time
that is allowed.  Rick said that he would address this question in a future
version of the document.

There was some discussion of the need for accurate (though not precise) time
at the client.  This is a requirement for short-lived certificates, as much
as for short-validity revocation information.  Gerv pointed out that it
would not be acceptable for a browser to modify the platform’s clock.  It
was pointed out that the browser could keep its own record of the offset.

There was also some discussion of nonces.  Yngve said that Opera does not
use nonces.  And Rick said that Symantec does not respond to nonces.

Yngve asked for guidance on how to respond to certain HTTP errors.

Tim suggested that the document should include a section on threats,
indicating which threats are addressed by the recommendations and which are
not.

Brad said that advancing stapling was probably the highest priority.  He
said that it should be mandatory to include revocation information in
certificates (except short-lived certificates).  Clients can use the policy
identifier to identify certificates for which revocation information MUST be
present.

Tim said that the revocation document should be on the Wiki.  Rick agreed to
post it.

Tim asked whether it would make sense to style this document as an Internet
BCP.  He said that he would open up discussions with the IETF Operations and
Management Area directors in order to consider whether the Forum’s technical
documents could be managed there.

12. 2013 meeting calendar

The following tentative calendar was agreed.

Feb-Mar.  Mozilla, Mountain view, USA.

May-Jun.  Izenpe, Bilbao, Spain.

Or

Symantec, Reading, UK.

Sep-Oct.  Entrust, Dallas, USA.

T: +1 613 270 3183

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120711/88af87ae/attachment-0004.html>