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

Mon Jul 16 08:05:35 UTC 2012

Richard,

Article 37 of the new EU regulation indicates the requirements for qualified certificates for website authentication and the qualified certificates can only be issued by qualified TSP as indeicated in article 3, definitions.

This EU regulation is for all EU countries, this is not about different legislation in different countries, so this will apply the same to the UK TSPs than spanish or German ones. There won´t be any difference between member states.

OTOH, this is a draft and have many concerns, and, for example, ETSI ESI have been discussing them from a Technical point of view and for example, I raised some concerns of what can happen to comercial CAs, the CABF members, etc. These, and others, have been included in a document that is going to be sent to the EU commission. I think there will be some other new drafts before the final version will be approved.

Regards

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: tScheme Technical Manager [mailto:richard.trevorah at tScheme.org] 
Enviado el: miércoles, 11 de julio de 2012 15:16
Para: Barreira Iglesias, Iñigo
CC: 'CABFPub'
Asunto: RE: [cabfpub] Notes of meeting, CA/Browser Forum, Gjøvik, Norway, 26-28 June 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/regulation/index_en.htm <http://ec.europa.eu/information_society/policy/esignature/eu_legislation/regulation/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/20120716/d6662bdf/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120716/d6662bdf/attachment-0004.png>