Face-to-Face Meeting 32 – Eilat

Antitrust Statement

The antitrust statement was read.

Roll Call

**Present: ** Ben Wilson, Dean Coclin, Jeremy Rowley, Robin Alden, Eddy Nigg, Kelvin Yiu, Iñigo Barreira, Rick Andrews, Atsushi Inaba, Doug Beattie, Don Sheehy, Kirk Hall, Gerv Markham, Moudrick Dadashov, and Wayne Thayer

Day 1 -Monday, 16 June 2014

SSL Performance WG

(prepared by Kelvin Yiu)

Wayne talked about goals, outcome, and how to get there. Thanks to data provided by Yngve

The WG initiated conversation on 3 topics:

1. certificate chain length

• Browser sees certificate chains are too long (>3). Obviously you want to minimize, but there are obvious reasons why chains are longer, such as private subCAs and cross signing (federal PKI, ubiquity).

• No one has identified what can be done, other than people tend not to make chains longer than necessary.

• Some server software always send the root and we can draft explanatory documents to educate people on chain configuration.

• Symantec has 1024-bit roots, and it is up to customers to decide when they want to send the cross certificate for compatibility.

2. Certificate size

• We can create a document that lists things people should avoid. The document would be targeted more at site owners than CAs and act as a best practice document that CAs can give to customers.

• The document should not be prescriptive.

• The document could say how to avoid overflowing congestion window rather than prescribing a congestion window size.

• There is already an O’Reilly book on optimizing SSL performance.

• Such a document may confuse a lot of our customers. e.g. CABF say there should be 3 certificates, but why is my CA giving me more?

• This gets into issues about outreach. How to configure servers, for which you would have to get into specific platforms. For example, IIS doesn’t let users control what certificates.

• The CA must also be sensitive about giving advice to customers. The customer may be wrong but thinks they are good because things are working.

• Classical example is the case where a broken certificate chain works in IE but not Firefox.

• Would we include recommendation on key size? Some people intentionally want to use 4096 bit key. Would they take advice? The document could explain the trade-off between security, compatibility, and other factors

• Is the document valuable enough for the CAB Forum to create? Is there a 2 pager with common mistakes that we can put on CABF site?

• Should the document be aiming for the CA? e.g. If 2048 is good for everyone, should CAs warn customers about the consequences if they choose a larger size?

• There has been no agreement among CAs.

• How many SAN fields you should put into certificate? If you recommended 10, people have said there are always cases where people would need more.

• From analyzing certificates in the wild, the data showed what we recommend is already what most CAs are doing. We can recommend against outliers but that is as far as we can go

3. TCP congestion window

• There was no consensus (the minimum window size ranged from 3 to 10)

• The scope seems to overlap with IETF and outside of CABF

Winding down the WG?

• What would people say about winding down the performance WG since there are other technical venue?

• First choice to use work already done by WG

• Let’s have someone in the WG summarize the parts that are useful going forward and only do the things that have promise. e.g. Recommend the number of SCTs?

• Concern: What about ECC? If you have full ECC chain, server is faster but clients are slower.

• Concern: IETF has a PERPASS WG that is focused on security. There is risk that the Forum recommendation could contradict IETF. This may give the impression that the CABF members care less about security.

• Let’s get a proposal on paper so we have vendor-neutral advice

WG chair

• It may be reasonable for Wayne to chair it on his own since Brian Smith has not worked on the SSL PERF WG.

• Group agrees. Wayne is now the chair

Summary

• Deliver a document that explains some of the consideration to be made on SSL Performance.

• Keep it short and focus on advice based on Wayne’s internal presentation. Focus on PKI-related topics.

• WRT to the conversation about the number of SANs. Ryan said to take statistics from the internet. We have data, but Wayne is not sure what to do with it.

• To keep the document up to date, the chair would have to put up a reminder somewhere to refresh the document.

Code signing WG

(prepared by Robin Alden)

We have a set of code signing requirements. We have a few open items, and when they are resolved we want to put it out to the CABF public list.

We’d like feedback from Adobe, HP, etc. MS has provided lots of useful info.

We need to get a peg in the sand in terms of getting the document out. It won’t be perfect 1st time around, but let’s see how we go.

1. Section 4 – Malware Database Provider definition: Iñigo would like more information on how to identify a malware database provider. There need to be steps a CA can take to identify relevant malware providers.

It’s a thorny issue. Much discussion over who/what/whether.

In 11.5 “.. identified by a: ‘reliable source’ as being suspect code” The ‘reliable source’ could be a CA, it could be a researcher, etc. to give the CA leeway.

13.1.2 – remove ‘Malware Database Provider’ because we need to allow other 3rd parties

13.1.3 uncapitalize ‘Malware Database Provider’ e.g. could be a researcher

13.1.4 drop ‘Malware Database Providers’

2. Section 8.2.2 – Should we still permit RFC2527? Probably permit it, yes. Not ideal but don’t want to forbid. Use a ‘Should not..’?

3. Section 9.4 – How long should timestamp certificates last? OCSP must survive as long as the timestamp is to be relied upon. Does the CA that signed the CS certificate or TS certificate need to survive as long as the latest OCSP status must? (Asked to hear from Oracle or Apple, but nothing yet). Ben wrote to Tim Polk, and Tim said “For CS & TS, the period of use for verification should greatly exceed the period of use for signing.” Kelvin says Windows doesn’t care. Suggests we leave it open (cf EU standard).

4. Section 13.2 – How long should a CA continue to provide revocation responses for signing and timestamp certificates? “A significant volume” is too ambiguous. 1%? (no agreement). Keep signing after the CS certificate expired. Keep signing even when the intermediate has expired.

MS will soft-fail if no OCSP response (http 500 or ‘UNKNOWN’). A CRL not being available will cause a hang.

We will suggest the Windows behaviour, and other platform providers can contribute amendments if they don’t like it.

Ben asked Rick to come up with alternate language by the end of the week.

Rick points to 8.2.1 (search for ‘expire’). ‘time-stamped’ should say ‘time-stamped code’. Rick says he will rewrite this line/paragraph.

5. Section 16.2 – Who is responsible for signed suspect code when it is a signing service? The signing authority or subscriber? Also, what is the appropriate protection mechanism? Rick says this doesn’t mention signing services. Aren’t there cases where the signing service screws up and signs malware with a subscriber’s private key – then it would be the service provider’s fault.

This section needs to split out the two cases – service provider/not.

The subscriber is responsible for protecting their private key.

Ben suggests deleting 2nd sentence and making 1st sentence stronger and split into two. Split between signing service and subscriber-controlled key.

Wayne: If subscriber holds the key it is not clear how auditable this is. An [acceptable] level must be specified in the subscriber agreement.

Kelvin: 16.2(c) the 128 bits is referring to key transport protection. It should be called out separately. (separate para in (c)?)

Wayne: We should say again in 16.2c what we say in 16.2b – that we want a subscriber’s warranty in the subscriber agreement.

Change the title ??

6. Appendix A(4) – What is the appropriate time to upgrade for timestamp certificates? Forcing all CAs to only use something 15 years ahead is impractical. Force them to stand up 15 years ahead, sure, but allow legacy use too.

Rationalize NIST and ETSI to come up with new figures for what we require. (Kelvin said he would do so)

Dean: We’ve had a rash of CS certificates out of China. While this process isn’t in this document so far, we now require the applicant to have a picture of the applicant holding their ID card and a newspaper, notarized letter, or something with a firm date, although they’ve had those forged, too. Ali-baba uses a similar standard, but does it prevent identify theft? They must have a notarized letter including front and back of an ID. (A webcam might be an option to present the same information to a live RA agent.)

Eddy says they already ask for a picture (on their website) and it works.

There is concern that this is a current good practice, but may only be effective for 6 months if it is adopted as a control, but we probably need to do something, even so. Ben suggests that we generalize this slightly to say something that allows the CA to incorporate a liveness element (picture & newspaper & holding etc.).

After lunch:

Operating a signing service – protecting the private key. Dean says, if you’re operating a service it should be compliant with networking security guidelines (and we should say that in this document if we don’t already), but beyond that we shouldn’t call out extra on signing service providers. Ryan was concerned about allowing signing services to use other than HSMs. Ben: There are other ways to securely store keys. Kelvin: If you take the position that the netsec guidelines provide a starting point, .. Dean: we’re saying for ‘C’ you’d have the same protection as SSL (as per netsec), and then you need some more too. Ryan reported as saying that a signing service is a greater target so should have better protection. Dean is going to take a pass at the document to see if he can improve the language. Perhaps state equivalent between signing service key protection and CA key protection.

Day 2 -Tuesday, 17 June 2014

Recap of Working Group Discussions

See Executive Summary prepared by Ben

Browser News

(Prepared by Wayne Thayer)

Microsoft (Kelvin)

We are investigating a change to the root list to disable CRL download and only use OCSP. Started thinking about this as a response to Heartbleed, but so far have not observed enough increase in CRL size to require the change.

Rick asked about current functionality where CRL is downloaded after a certain number of OCSP responses have been retrieved. Kelvin said that this was also covered by the change.

There is a test location for root updates that currently includes this change. (The config is part of the root store format, not part of Windows itself.) Kelvin will again send out the location to the Management list.

Microsoft is deciding if they will ask CAs and make the change on a per-CA basis, but they may do it across the board since it’s similar to the behavior of other browsers. This change would apply to both end entity and intermediate certificates.

Kelvin described another setting in Windows where all revocation checking can be disabled for CA certificates. Microsoft is considering turning this on and using their “untrusted list” to revoke CA certificates – similar to Google CRLSets. Their blacklist gets refreshed every 16 hours, so it’s much more effective than most CA root CRLs. Kelvin said that their “untrusted list” can scale to ‘tens of thousands to millions’ of certificates.

To operationalize this new approach to revocation, Kelvin needs to know the list of CA CRLs that Microsoft needs to check, or obtain an agreement from CAs to notify Microsoft on revocation.

Gerv – Mozilla is also interested in list of CRLs of subordinate CA certificates. Gerv would like one mechanism for CAs to notify all browsers.

Rick – I also asked for that in the past.

Ben – what would it take to standardize this? Can we use the CA/Browser forum List server?

Gerv – now is not the time to define the tech spec.

Ben – can we create a working group to standardize this? Specifically the policies and process that need to surround this. For example, exemption for subordinate certificates that were never used. Some of this can be added to the BRs.

Kelvin – some of it will be part of the browser root program requirements

Gerv – agreed that we do need a working group to work on this

Iñigo – ETSI decided that CRLs are not required for Qualified end entity certificates. ETSI hasn’t decided on their rule for intermediates.

Mozilla (Gerv):

1 – Revocation

Want revocation to work but be fast. Heartbleed proved the need for revocation. Also working toward hard failure. CRLs and direct OCSP are too slow for hard fail. OCSP stapling can be stripped out by a MITM without must-staple. Mozilla believes both OCSP + must staple and short-lived certificates are the answer, depending on application. They will do something like CRLSets for intermediates. They feel that CRLDP should be required in the root/certificate above the intermediate to make CRLsets easier.

Rick – in BRs today, CRLs are not required. It sounds like Mozilla’s mechanism will include all intermediates. Google’s CRLSets do not.

Gerv – current plan is that their mechanism will include all subordinate CA certificates.

Rick – that’s a fundamental difference with CRLSets, so don’t call it the same thing.

Jeremy – is that for phone or just desktop?

Gerv – both, because the performance problem applies especially to mobile

Kelvin – there is a single codebase for PKI across desktop Windows, Windows Phone, and xbox

Iñigo – CRLs aren’t required by EV Guidelines

Jeremy – BRs 13.2.2 say that you must have CRLDPs for subordinate CAs

Ben – we can clarify and work on getting all CAs compliant

Gerv – if all the browsers agreed on the mechanisms

2 – CA Transparency

Subordinate CAs must be technically constrained or audited. Thanks to all who helped implement this. Now considering loading a set of all known intermediates and filtering those not disclosed.

Jeremy – would it then take a long time for a new intermediate to be ubiquitous

Gerv – possibly, although a dynamic update mechanism has been proposed. Currently just making CAs aware that this idea has currency, and asking for feedback

Kirk – to clarify, Firefox will error on subordinate CA certificates not on this list.

Gerv – correct

Jeremy – this would encourage creation of a bunch of pre-generated intermediates

Gerv – that’s the kind of feedback we’re looking for – law of unintended consequences

Rick – nothing stops the EFF from using disclosure information today. It’s in a public Mozilla bug

Kelvin – MS would also like to see all subordinate certificates – not just SSL. Would like to get to the point of requiring this disclosure

Wayne – how does this compare to CT?

Gerv – basically CT for intermediates

Rick – the concern is that every browser creates a separate mechanism the CA has to implement

Rick – does disclosure requirement apply to non-SSL intermediates? When are CAs expected to disclose new intermediates they’ve created?

Gerv – ask Kathleen. She is evaluating using a salesforce.com tool that will allow CAs to manage/update information

3. Key pinning

FF 32 will pin Twitter + addons.mozilla.org. FF 33 will pin all Google properties. These are preset pins. Implementation of HPKP is further out, but planned

Gerv – currently just using Google’s pin list. Open to creating a shared preset pin list project if conditions warrant it

4. May 2014 CA Communication

information has been published: https://wiki.mozilla.org/CA:Communications#May_2014_Responses.

Saw generally good compliance. Thank you.

Rick – what is status of CAs that said they wouldn’t be BR-compliant until 2015?

Gerv – Wanted to ask the group about this. Considering technical constraints. Lack of OCSP and 1024-bit keys are common reason for non-compliance

Kirk – how about a non-compliance pop-up?

Gerv – not likely to happen – bugging users who can’t do anything about it isn’t good. Technical constraints seems like best option. The current constraint mechanism in NSS may need some work before this is possible

5. mozilla::pkix

Due to ship in Firefox 31 on July 22.

Now is the time to test. Thank you to CAs that have already been testing and filing bugs.

Iñigo – what about OCSP response duration for intermediates?

Gerv – I think this was changed back to allow a maximum of 1 year for now

6. Definition of SSL certificate

Mozilla thinks it is a good idea to get concrete. Looking for browser consensus

Kelvin – Is this specific to browsers?

Gerv – certificates that the BRs apply to are the things they’re concerned about

Jeremy – browsers requiring serverAuth EKU could do this

Kelvin – sees certificates without serverAuth EKU. Also sees anyEKU and Windows will recognize that per PKIX

Kelvin – we also see intermediates with anyEKU that can issue SSL certificates but aren’t intended for that

Iñigo – ETSI would like a good definition of an SSL certificate

7 Must staple

Mozilla working on an implementation. Considering use of an X.509 extension as specified in the current IETF draft or adding it to the existing certificate policy extension. Would it be easier to implement in a CP extension? Please comment on this on the IETF working group or email Gerv if you have an opinion.

Kelvin – will check to see if the Microsoft CA has any problem adding new unrecognized extensions to a cert.

Gerv – second question for CAs would be if certificates with must-staple could be required to be issued from an intermediate containing a must-staple OID? This would help with proxies.

Jeremy – that would be hard to do

Eddy – but these are untrusted roots

Kelvin – why not differentiate a trusted root from one installed by the user or enterprise?

Gerv – there’s no way to distinguish this in the Windows root store

Kelvin – there is – will talk offline

Jeremy – changing out intermediates would be very hard. Others concurred.

7b Could certificates be marked as being used for MITM?

Browser would display this. Require EV-like vetting of company.

Robin – this won’t work for antivirus software installed on the client

8 – Validity period – short-lived certificates with no revocation should be an option

Validity periods should be tied to OCSP validity period.

Kelvin – are we endangering CAs by doing this because they are closer to the internet?

Gerv – there’s no difference

Rick – what about clock skew?

Jeremy – barrier to short-lived certificates today is that OCSP is still required by BRs. Prior proposal didn’t receive enough endorsers

Gerv – considering shortened OCSP validity periods – maybe just for must-staple.

Jeremy – study by Rob Stradling showed client clock skew can be up to 3 days

Kelvin – back on short-lived certificates, isn’t human touch required to request and approve a cert?

Ben – we’d need to modify the BRs to account for short-lived certificates. This would could be given to a working group.

Report from WebTrust

(Prepared by Ben)

Don: The last time we met we had just released exposure drafts for EV, Baseline Requirements that included the Network Security Requirements, and we did not receive any comments from Forum members on them. Now we have final versions published. These are effective July 1 for audit periods beginning on or after. This gives the Forum an opportunity to clean up the Network Security document where requirements are vague or too detailed.

Kirk: What if our audit cycle starts May 1?

Don: Even though you would not have to comply, we encourage CAs to start early, because one of the browsers might require it. We discussed the issues to fix at the last meeting. You have the list of things to look at. We understood you were going to take a look at the NIST document and get back to us.

One recent development has to do with the seal program. The AICPA has been more concerned recently about liability, less than CPA Canada. Therefore, we are revamping the auditor licensing agreement. There have been concerns about smaller firms and auditors outside North America where it may be difficult to confirm the credentials of the auditor wanting to be a licensee.

We are also revamping the relevant technical requirements that are expected of an auditor that were developed by the Federal Bridge and other ones that are part of generally accepted auditing standards, so we’ll be dealing with issues such as: the number of years of experience in delivering PKI assignments, experience in IT control audits and complex systems, the fact that they are licensed accountants, etc. It will be a fairly extensive list. Also being talked about is that the actual team members proposed for the engagement will need to be sent to CPA Canada to become a licensee for Web Trust in advance of them actually receiving the license to use the audit seal. Moreover, CPA Canada will likely request time summaries once the audit has been performed but before the seal is issued. It will compare who you said was going to do the work with who actually did the work. So, in an engagement using outside contractors, the auditor would have to provide the specifics and with the assertion you would have some evidence that the examination has been performed appropriately. One issue is whether the seals give the right for CPA Canada to come in and review the audit files, which some organizations would block on the basis of confidentiality, but they probably don’t realize that they signed up to that in the license to use the seal. We’re trying to avoid that because we’re not trying to reassess or challenge the audit results but to ensure that they are using competent people in the actual conduct of the audit.

Along the same line, we’re developing detailed practitioner guidance so that auditors will have that as background.

One effect is that the WebTrust seal will have more strength than it traditionally may have had. Most of the engagements are undertaken by the Big Four firms, but there are some that have been done by small firms, and sometimes firms outside North America will approach WebTrust at the last minute. So this will help control this seal license issuing process and will help keep the AICPA satisfied, because frankly, the last thing we want to see is the seal program pulled because they are presented on client sites and people can actually find out about the audit. It provides a link back to the audit for public reporting which everybody in the Forum wants. Otherwise it is difficult to determine compliance.

Our expectation is that because our next meeting is planned for August before Beijing we will have the revised licensing in place for the practitioner. That is our next major project. We’ve got at least all of the measurement criteria nearly finalized now.

When was our agreed upon date? Was it September 30 or October 31? What we will probably do is wait until after the next meeting when changes are finalized, and unless something comes up, then we might have to incorporate the change by reference.

I’m hoping for better trained auditors. We’re not in the business to restrain trade. Our sole goal is to ensure that audits are performed by qualified individuals. Let’s face it, the requirements keep getting more significant all of the time– for both ourselves and ETSI. One saving feature has been that PKI failures have been few, and fortunately none of them were Web Trust audit failures. We just want to make sure about our priorities and that the quality continues.

Also, Bryan Walker has developed a Baseline Requirements seal if any are interested. Questions?

Dean: The audit of Network Security Requirements is in place as of July 1?

Ben: My concern is that audit firms have been slow getting ready for these newly effective criteria.

Don: Well, we have three of the Big Four at table. But I’ve just got one quick question: are people getting their audit reports within three months of their audits? Are you experiencing delays in getting your audit reports?

None.

Eddy: I find that auditors are busy around January.

Don: There have been some minor edits to the documents. I’ll talk to Bryan about getting those up.

Ben: What about the URLs on your website? The user just sees a number instead of the name of the document.

Don: Hopefully CPA Canada can do something about that.

Report from ETSI

(Prepared by Ben)

Iñigo: The EU Parliament ratified the document presented by the EU commission so that means we have a new regulation. We have a new parliament in July, and in the meantime this regulation is being translated into the different European Member States’ official languages, Spanish, etc., so that by the end of July the Council will ratify the document approved by the Parliament and this regulation will enter into force, which means that by July this year, all 28 Member States will have a new law, common for all countries, on electronic signature. This regulation starts with electronic identification, focusing on identity, and then you can use your identification for electronic signing, electronic seals, and website authentication. It also addresses the new concept of TSPs – Trust Service Providers – there is no more use of the term CA or CSP, just TSPs, TSPs that issue certificates, TSPs that provide timestamp certificates, or TSPs that provide validation and signing services, or registered email services, long-term preservation of information.

We are working on the deliverables, the documents, and for the new regulation there are a lot of changes that browsers should be aware of and that will affect non-European CAs and other third parties, those that are non-European / American, and the way you have to work with the EU. This regulation has recitals and Articles which are referring to what ETSI is doing, and it is not finished. There is secondary legislation that in two years’ time, every Article will have an implementing act, which will say how and when to implement the act. It delegates and allows countries to specify their identification schemes, but other parts are implementing acts by the Commission, so that all Member States of the EU will have to do the same everywhere. So it won’t be that this country is doing these things this way, and this country is doing it in a different way.

In July this year, the Council will ratify the text approved by the Parliament, so it will enter into force. But only the Articles exist, so there is no way that a TSP will be able to implement it. Some provisions of the implementing act will have one year to implement and others will have two years. The idea is that by July 2016, all Articles will be effective and then you will have to observe it as law, but you cannot wait until July 2016 to start. This is called the two-year migration plan.

Slide 4 ETSI-Israel-4

TS 102 042 remains the compliance standard for members of the CA/B Forum operating under ETSI seeking inclusion in browser root stores to say they are following the Baseline Requirements. This ETSI “TS” is going to be changed to an “EN.” It is a European Standard, which means that it is mandatory for TSP CAs. Some of the requirements will depend on what the implementing act says. Currently TS 101 456 is for qualified certificates. EN 411-3 will replaced one or two offered to the public key certificate but EN 411-3 does not include the SSL-type certificates, which are of interest to the CA/B Forum. Only TS 102 042 still does.

On the other hand, at the last meeting, Microsoft and Google said that they wanted all certificates accepted by browsers to comply with the Baseline Requirements. This is a problem for us because the regulation is a law–it is legal. A browser cannot impose a requirement upon us that conflicts with EU law. In ETSI we are trying to fit the requirements of the Baseline Requirements to apply only to those public key certificates that are going to be publicly trusted, but not for the qualified certificates. Qualified certificates must be according to the regulation and have different implications. We would like to have just two documents–one for public key certificates and another just for qualified certificates.

We are working on four documents. EN 411-1 is for TSPs issuing website certificates. EN 411-4 is for attribute service providers, and we are thinking of having EN 411-5 for code signing. We’d like to have these all in one document for browsers, CAs, TSPs, to use. We also have EN 412 for profiles, so 412-4 is the profile for website certificates. Currently we are using the same definitions and the same profile as the CA/B Forum in the annex. We are not adding any specific extended key usage or any key different key usage, but if we merge all of the documents into just one, then we will have some differences. Again, these documents are for policies and profiles. These policies are for the TSPs seeking to be admitted by the browsers. We will let the browsers know when they have to change the references in their root programs from the old TS style to the new EN.

We also have requirements for conformity assessments under EN 319 403. They are the requirements that auditors have to meet to perform ETSI audits. We are going through the qualifications for the auditor. It has to be done by ISO 17065. ETSI is suggesting to the browsers that they only accept audits done by accredited auditors. We’ve asked Mozilla, Microsoft, etc. for a list of CAs audited. We also asked the main auditors in the EU and the National Accreditation Bodies in every country to check whether auditors are accredited according to their National Accreditation Body. We have found that some companies are not accredited and that some CAs with these audits are in browser root programs. The regulation is coming into force, and the auditing bodies will have to follow the implementing act and EN 319 403, and so we will ask the browsers to accept only ETSI-accredited auditors to perform ETSI audits to ensure uniformity.

Don: How will you know whether they are accredited?

Iñigo: We have an ETSI website with a list of the accredited auditors. Someone can go and look at them.

Kelvin: It will make it easier for browsers to go and see who is accredited. How do you go and see who is accredited elsewhere outside of the EU?

Iñigo: The ENs are not only for the EU Member States, so if there are companies outside of the EU claiming conformance to ETSI, they have to follow the same standards. So if you are not in the EU, and you as the TSP want to hire them, you have to check and confirm that they are accredited, in your country, or in another EU country. That country is required to have an accreditation scheme for performing this ETSI audit and the list where you can check.

For example, we do not have any accredited auditors at the moment in Spain. Our National Accreditation Body does not accredit any ETSI auditors. So I have to find out where to get these auditing bodies – I checked with the Netherlands, then I moved to TUV-IT in Germany. We did this research and found that only a few of them are accredited. There is another one in France, and another one in Denmark. But we found some in Poland doing audits that are not accredited and not on the list. When the regulation and implementing act indicate that you have to follow these requirements, then the auditor you use to perform your audit has to be on the list.

Ben: Let’s assume the CA is located in Japan and wants to use ETSI, what do they do?

Iñigo: They can be accredited in Japan if they have an accreditation scheme in Japan. They can be accredited in Germany if they are following the German accreditation scheme. That is similar to what WebTrust does. When I had my WebTrust audit, a Spanish Web Trust auditor came, so this is not only about Europe. There are some standards that they have to comply with in EN 319 403. One Japanese CA has its root in France, and they are audited in France by French auditors even though they offer their services in Japan. The Japanese people know that they are ETSI-certified.

Also, it is also about where you provide the service. The idea is to audit everything. For example, QuoVadis is in Bermuda and is ETSI-audited. If you are certifying your issuing service, it doesn’t matter if you are in many locations, it is where the issuing and registration services take place. Because part of operations were in the Netherlands it was being done by KPMG in the Netherlands.

These are being revised to align with the new regulation because we have a mandate from the Commission to convert all of the 1999 standards to ENs. The new implementing acts are going to require that we change these standards. The regulation is going to be approved in July, so I will have further details to provide at the Beijing meeting.

[Slide 5] – ETSI-Israel-5

This slide is about the deliverables of interest to the CA / B Forum. First, EN 319 401, which is a general requirements for all TSPs. These general policy requirements include the Network Security Requirements of the CA / Browser Forum. For any kind of TSP, for certificates or for timestamp tokens, or a TSP for validation of signing or validation of the certificates of any kind, the TSP must follow this EN 319 401.

According to the regulation, there will be a qualified service and an unqualified service. For qualified service, you need to be certified. You have to undergo EN 319 411-1 policy and security requirements for TSPs issuing certificates, in this case for website certificates.

EN 319 412-4 is a profile for web site certificates.

EN 319 403 is the conformity assessment for TSPs. The link is where you can find something the work of STF 458. Also are the cryptographic suites and key lengths in TS 119 312. It is not about the sunsetting of SHA1 by Microsoft. At the moment, it is a recommendation that depends on the implementing act.

Kirk: Does every European country get to do its own implementing act?

Iñigo: No. The Commission will determine what implementing act will apply to every Article, and every European state will have to follow it. It is not as we have now with different electronic signature laws with different ways of implementing it, etc.

Kelvin: So that does not mean that every non-European state would have to follow it?

Iñigo: That’s the next question. There are some articles and recitals that say if you have to operate in Europe, you have to follow them. So that is an area that might be controversial to CAs and browsers.

Some of these are still in public review. I sent some links for you to review and provide comments. None of you did. After our meeting at Google in Mountain View, we had a meeting in Barcelona. I mentioned the intention of Microsoft and Google of applying the Baseline Requirements for all type of certificates to be used in the browsers. So, we are trying to reduce the number of ENs. The EN 319 411-1 was meant to address the policy and security requirements for all public key certificates, including website and code signing, even if they are not intended to be publicly trusted but because the way the Baseline Requirements are written for publicly trusted certificates. And you can issue public key certificates that are not publicly trusted because they are not in the European trust list. And I am working on this, so if you have to complain about the resulting document, well, I’m still thinking about it. For the last three weeks I’ve been thinking about how to achieve not publicly trusted in the browser but publicly trusted in the trust list. Adobe released information last year about using the EU trust list. It’s maintained by each EU member. We tried something similar with the browsers, but haven’t been able to.

[Slide 6, Bullet 4] – ETSI-Israel-6

– We also recommend the ISO 27000 family of controls for security measurements. They are incorporated into the 401 as general requirements and in 411 as specific requirements for every type of certificate. You could become ISO 27001-certified, but you do not need it from the browser perspective.

Kelvin: What does it mean to get an auditor who is ISO-certified, if you’re doing one of these audits, does that mean that I am also getting ISO-certified?

Iñigo: No. You don’t get an ISO audit, it’s just for the controls. We can do a mapping between ISO 27001 controls and they are related to the 102 042 and 101 456. There are specific controls of the ISO that apply to the ETSI, and that’s all. There is another working group in ISO working on PKI–one of the options for the banking area to replace 21188. They have a study group that decided to follow 15645. Their goal is to have an ISO standard for PKI audit by the end of the year, but it will take some more time. It will have an ISO 27001 focus on PKI. It will be a PKI profile.

We will have a checklist for auditors in which they will take the common requirements of 401 and the specific requirements of 411. We have an Excel worksheet in which they can check all of the different services – issuing, registration, validation, etc. when they perform the audit.

For EN 319 403, we will address the process and report on the capabilities of using ISO 17065.

In summary, we are trying to adapt and reduce the number of documents based on browser requirements to use the Baseline Requirements for all types of certificates–but not for qualified certificates–just to let browsers know that qualified certificates are not going to be included in these and to check that before.

[Slide 8] EU Regulation – ETSI-Israel-8

Here I have the regulation for you to read, and so you can read every Article, and maybe you have a different interpretation. We haven’t yet talked officially to the Commission to know what they understand by, for example, a qualified website certificate. We have not discussed whether this is an EV certificate. For instance, at the CA Day in Berlin, you may have been listening to Gerard Galler say that they want the EV certificate to be the qualified website certificate in Europe and to have DV, OV, EV and EV qualified website certificates. Browsers would have to check whether it is one or the other.

Ben: This would be in addition to EV, mainly for government use, right?

Iñigo: In Spain we have qualified website certificates for use by the public administration.

Moudrick: Relying parties can just use the TSL …

Dean: I don’t think browsers are going to do that.

Moudrick: … like Adobe.

Ben: You could have browser plug-ins that do it.

Jeremy: Right, but a plug-in is different than a built-in capability.

Iñigo: Let’s get back to the regulation.

Jeremy: There can be regulations that require the use of a trusted certificate, but there is no regulation requiring CAs to issue qualified web site certificates or for browsers to show that it is a qualified certificate.

Iñigo: But there is a new definition of services, and for qualified certificates the browsers have to do something to distinguish these.

Jeremy: Why do they have to do something? What’s the law that requires it?

Iñigo: If they start checking the OIDs, to show differentiation among DV, OV, and EV, there will be another OID.

Jeremy: But they are not checking OIDs, per se. They check to see whether it is chained to an EV root.

Kelvin: We check OIDs for EV.

Jeremy: For EV, but not for DV or OV.

Iñigo: But Microsoft said at the Mountain View meeting that they would like to have all the types of certificates to be compliant with the Baseline Requirements, so maybe it is understood that if they had to be BR-compliant that they are going to check for OIDs, but I don’t know. I asked Tom, “all types of certificates or just SSL?” And Tom said, “all types of certificates.” Ryan said, “only SSL, at the moment.”

Dean: Let’s get back to Slide 8.

Iñigo: The Regulation was ratified by the EU Parliament on 3 April 2014 and formally ratified by the Council. The text will be translated into all EU languages and entry in force by July 2014, but that may be delayed. Then develop the implementing acts within 1 year.

Ben: Who does that?

Iñigo: It is being done by the Commission, not ETSI. The key date for the Forum is July 2016. This regulation places requirements on all trust services (including providers of web site certificates) providing services to the public and established in the EU. If you are not established in the EU, but you want to operate in the EU, you still need to comply if you want to provide services.

[Next Slide – Slide 9] – ETSI-Israel-9

Recital 73 is going to be controversial because it only says “in particular, CEN, ETSI, ISO, ITU”. This recitation does not have an implementing act, so it is a little unclear. I asked the Commission about WebTrust and they said it is not an official standardization body for trust services. So you can all read this just as I do. The CA/Browser Forum is mentioned elsewhere in the regulation.

Robin: One scenario–if as a Trust Service Provider I am on the European Trust Service List, but I don’t provide qualified certificates as a CA on the trust list, then what?

Iñigo: If you are a TSP that is not providing qualified certificates, just website certificates, then you are not on the TSL. There is another Article for trust marks. So like WebTrust, you would provide evidence to browser root programs.

Kirk: Is it correct that if I am a WebTrust-audited CA that is not located in Europe, and I want to sell OV and EV certificates in Europe, I do not have to comply with this?

Iñigo: This is in the next slide [Slide 10] – ETSI-Israel-10 Article 14 – International Aspects. “Trust services provided by trust service providers established in a third country shall be recognized as legally equivalent to qualified trust services provided by qualified trust service providers established in the Union if the trust services originating from the third country are recognized under an agreement concluded between the Union and third countries or international organizations in accordance with Article 218 TFEU.”

Jeremy: If you are in the EU, and you do not want to provide qualified certificates, you do not need to comply.

Kelvin: Who would use this?

Iñigo: Qualified is not just for government. It is for anyone who wants to know that you are certified and accredited for what you are doing. In Spain, for example, there are more than 30 CAs. Some of them a non-public, semipublic, or semiprivate and some others are banks that issue qualified certificates for their employees, for performing tasks, etc. Those CAs must follow this regulation, even if for internal PKI, they have to qualify.

Jeremy: That is my question, where is that regulation?

Iñigo: Because, you have to qualify if you’re providing qualified trust services you are in the trust list, and these banks are in the trust list because, if for any reason you have to sign anything with your corporate bank ID certificate and send to Germany, then they have to be able to check that the provider is in the trust list, for example. If it is only being used to apply for your holidays at work, then then it is not needed. This regulation is about interoperability. The EU members want to have the same levels of assurance and identification schemes. If my country determines that a medium level is appropriate for doing a certain task, then I have to meet all of the levels that have been defined by all of the other countries. The purpose is to set the same requirements for everyone–independently, if you are in the EU and you are issuing qualified certificates. If you’re not providing qualified services then this is not applicable you. The concern is that during the last CA Day, Gerard said that the EV certificate will be like the qualified website certificate. If EV is going to be considered, which it is not at the moment, as a qualified website certificate, then you are under this regulation and you have to comply with this. So let’s assume you are in the trust list and you are providing EV Certificates as qualified certificates, then you have to follow the regulation and sign an agreement with the EU.

Jeremy: … which depends on whether all EV certificates are deemed qualified certificates.

Iñigo: Next question – what about code signing certificates? Will EV code signing certificates be qualified code signing certificates? I could request that my EV certificates be included in the trust list, just to sell in other countries. What if I said my EV certificates are in the trust list if you want to check that I am performing according to my country’s rules? In 2006 or 2007 Spain adopted a new law for electronic seals for public administration and website certificates, which they called “qualified.” So assume that I have two types of my certificates in the trust list. To be recognized by the browsers, I had a qualified website certificate for public administration and a qualified website certificate for public administration with EV. Those EV, which are green in the browser, are in the trust list.

Don: I’d like to go back to the Commission and ask why they don’t recognize the AICPA, Canadian Institute of Chartered Accountants, or IFAC, because I think the legal folks would be interested in that information. It’s not WebTrust, it’s really those organizations who need to be recognized.

Iñigo: Well, I said, “what happened with the WebTrust CAs?”

Don: I think they ought to go on record stating why they don’t think the AICPA, CICA, or the International Federation of Chartered Accountants are not standard-setting bodies, especially when Europe follows IFAC standards for accounting and controlled measurement.

Iñigo: I could ask, but it is the same question for why it did not include the IETF, which we use often. It was written by the Commission and ratified by the Parliament.

Kirk: It is not limited to the four named.

Iñigo: It’s just a recital, not an article, so it may not be that important. I can provide you with Gerard’s email address if you want to send him a message stating your request to include AICPA, CICA and IFAC, but this is what it says–I’m not trying to interpretate.

[Slide 11] – ETSI-Israel-11

Article 18 security requirements applicable to all trust service providers to manage risk and follow developments, and to provide notice within 24 hours of any breach of security or loss of integrity to the supervisory body and other participants. “Communicate within 24 hours of any breach of security or loss of integrity to the supervisory body and others (third parties, ENISA, etc.)” We would like to have better communication and coordination in light of what happened with Diginotar to let others know what is going on. Here is the Article, and there will be an implementing act on how to do it. They will provide an email address or some other way to notify the supervising body. Article 19 changes audits to every 24 months. At the moment we have the audit every three years, but now it is going to be 24 months or two years.

Kelvin: Why not every year?

Iñigo: Every year we have a surveillance audit. The certification is for three years and every year we have a surveillance audit. We also have observations for minor nonconformities, so wherever they are checking if you have a fix, etc., and now it will be every 24 months. ISOs are every three years again.

Article 20 is on penalties. So you do not comply with this regulation you can be fined. “The penalties provided for shall be effective, proportionate and dissuasive.” Under Spanish law there are fines, which are high enough to put a CA out of business. Some CAs are not in the business of making money selling certificates.

They are also considering CAs as critical infrastructures. So with this regulation and law, things will change as CAs are included as critical infrastructure.

[Slide 12] – ETSI-Israel-12

Article 23 is about the trust mark for qualified trust services. It was talked about during the last CA day. There will be another CA Day in November in Berlin, during which we’ll talk about the regulation, of course. Trust mark is not a one-time, one-size thing. For every service you provide you will have to apply for a trust mark. So, for example, in my case for Izenpe, I have a qualified EU trust mark for qualified certificates. If I also issue qualified timestamps, tokens, etc., then I will collect a lot of EU trust marks.

Article 24 is about requirements for qualified trust service providers, which we have discussed.

[Slide 13] – ETSI-Israel-13

Article 43

Ben: It seems to me that if you are going to make EV a qualified certificate then it is easier to make “qualified” an add-on to the EV certificate. And if you are a qualified TSP issuing EV according to qualified requirements it becomes a “qualified EV certificate.” So we do not need to create a new set of rules. The only downside is that the Commission would not want us to change the EV Guidelines because that would be changing the underlying basis for picking the EV certificate, so I guess maybe that doesn’t work.

Iñigo: In our reorganization work on EN 411, policy requirements, the qualified web site certificate is going to have a specific policy. For qualified certificates it is not going to be under the public key, so we’ll have different implications than we have now. We’ll create a new OID.

Kelvin: So for publicly trusted SSL certificates, will it will be under a qualified chain?

Moudrick: This is a new type of certificate.

Kelvin: Can these certificates be used for SSL? And if they can be technically used for SSL, then they’d have to meet the Baseline Requirements.

Iñigo: We’re thinking on setting up in the new profile an inclusion of the QC statements, for QC compliance, qualified retention periods, and the SSCD, for qualified code signing. I will be asking the CA/B Forum to change the profile in the documents to include the QC statements.

Ben: We can say in that area of the profile that it is optional.

[Slide 14] – ETSI-Israel-14

Iñigo: We’d also like to change the key usage and extended key usage. So if you have concerns about Annex IV, please check it and send to me any comment you think is correct. We can also issue qualified website certificate for authentication of natural persons.

Kelvin: What things are missing in EV and what are the things that can be fixed? I’m trying to understand more about the issues here.

Iñigo: The level of assurance is in the regulation and depending on these levels of assurance you have to identify people in different ways.

Jeremy: And as CAs we have to be aware of the national requirements and disclosure laws and compliance, etc.

Moudrick: In technical terms, it is as easy as deciding whether you are relying on the trust store or the TSL.

Kelvin: OK.

[Slide 15] – ETSI-Israel-15

Iñigo: The profiles will be official without this reorganization by the end of September and the policies two months after that. The ENs will be final unless the implementing act is so different that we have to change the ENs, but then we have to adopt or update the ENs. In summary, the regulation is important to the non-European CAs is that those that want to offer qualified services in the EU have to follow this procedure. You have to have an ETSI audit, although it is not clear why WebTrust is not permitted. Second, you have to be on one of the European trust lists or apply under Article 14 for a country agreeing to operate a supervisory body.

Ben: US companies would have to get the Department of Commerce to sign an agreement with the EU Commission or become cross-certified.

Iñigo: You could contact Gerard Galler to see if there are other options. I’m just the messenger, and I wanted to present what the regulation says. Thanks.

[Slide 16] – ETSI-Israel-16

Update on SHA1 Sunsetting

(Prepared by Doug)

Eddy noted that many systems are not ready for SHA2. Windows 2003 Server has a special update available, but it is set to end-of-life next year. Some customers have trouble making the move to SHA2, so they come back and ask for a SHA1 certificate. Kelvin encouraged CAs to contact him if they have specific examples. Eddy asked if Kelvin he had any statistics available on how many Windows 2003 servers were in use.

GoDaddy: Only issuing SHA-256 (can support manual processes for SHA-1). Have not had any major issues. They were asked if most of their SSL customers were also hosting customers, they said no.

Symantec: No inflection point – issuing same number of SHA-1 and SHA-256 certificates now as in the past. Commented that if you change the intermediates, then users get tripped up

DigiCert: If you want a certificate past 2017 you default to SHA2

Comodo: Sends along full chain in fulfillment email, uptick in May noted on Netcraft

GlobalSign: Defaults to SHA-256 on ordering pages, no issues to report.

Microsoft

• No changes to official plans, but they are considering some minor changes to align better with Windows releases
• Code signing: Haven’t agreed on policy for SHA-1. They are not sure when they can provide the updates to add this capability for Win7 and Vista. Might need to revise the dates so they align with the ability for these platforms.
• Code signing SHA-256 requirement might align with SSL, one year slip, TBD
• Symantec recommends not making major changes like this on the first of the year, others agreed.

There was a lot of discussion around Code signing and time stamping validation rules. Nothing was agreed to, but there is a need for the industry to understand the validation rules regarding code signing. This should be a topic for future meetings.

There are 3 hashes to consider and ideally they should all move to SHA-2 together. All code signed after the date will only validate if everything is SHA-2.

• Signature on the code
• Code signing certificate
• Time stamping certificate

As of 1/1/2016, signed code will be “grandfathered” and continue to be valid even though it uses older hashing algorithms on timestamps, certificates, or the code. On the cutover date all existing applications will continue to operation and only newly signed applications will need to comply with the new policy.

Can sign-tool be updated to detect mismatch and warn the users about the upcoming changes?

• MS said they could ship an update, but there are challenges with users getting the updated code sign tools. Many people are still using MD5 signatures and this was phased out in 2001.

There was a recommendation that MS phase-out MD5 prior to deprecating SHA-1. It’s unlikely this will happen, but perhaps if the SHA-2 date moves, then there might be time for 2 events, one for MD5, one for SHA-1. MS recommends that the CAs help educate the end user to get updated code sign tool regardless.

Additional discussion of Code Signing Guidelines

(See Executive Summary)

Discussion of CAA proposal

(Prepared by Gervase Markham)

Rick presenting. The Current State of CAA

The proposed text binds the CA to consider the CAA record, and describe the procedures in the CP/CPS. It is permissible to ignore the records completely.

The Pros

• CAs can build it on their own (no browser support needed)
• It’s relatively simple for the customer and the CA
• Customers have to opt-in, so deployment is likely to be minimal for the next few years
• It’s not for everyone, but it gives some customers a useful tool
• It demonstrates our willingness to act to prevent mis-issuance

The Cons

Rick’s slide contains notes from previous phone calls.

• Risk of anticompetitiveness – but companies may want to decide who has authority
• Risk of policy conflicts within a company – but PHB says they would be rare
• Risk of anticompetitiveness – but CAs could refuse to honour records from bad actor
• Problems with cross-company subsidiaries – but CAA allows more specific records for subs
• Risk with it becoming a “Do Not Issue” list – but it’s not an absolute prohibition
• Risk that a DNS admin’s decision might not be the opinion of management
• Risk that orgs are too complex – but then they probably won’t deploy a record

Gerv talked about the importance of gaining experience of how well CAA works in practice.

Iñigo suggested, perhaps not entirely seriously, a defined minimum of two CAA records per domain.

Not sure what would happen to a ballot; browsers would probably support but the CAs seem split. Eddy said he actually probably wouldn’t vote against.

Update on Public Suffix List

(Prepared by Rick)

Gerv said it’s an attempt to make a map of divisions within DNS. Exact language to talk about these divisions is tricky.

https://publicsuffix.org/list/effective_tld_names.dat

Search for “BEGIN”. See that the list is split into two parts – ICANN and PRIVATE. ICANN suffixes are those controlled by entities in a relationship with ICANN. PRIVATE suffixes are the other sort. The Baseline Requirements should be telling CAs to check only the ICANN section for wildcard checking and general evaluation of what is the customer-owned domain name; assuming you are Google, it’s entirely OK to have e.g. a *.appspot.com certificate. The BRs can say that a CA can disregard the lower section of the list.

Gerv said the list was split (the PRIVATE part was added) two or three years ago; Mozilla didn’t make a lot of noise about it.

We agreed that if we change the BRs, the change is informational only. Should we change BRs to say that CAs MUST use the PSL, so that there is consistency among all CAs? The consensus was yes.

Concerning ICANN’s new TLDs:

Default behavior if you encountered a suffix that wasn’t in the list: you treat the last label as being in the list. Some have come up with new uses for the PST like Chrome’s omnibox for distinguishing a URL from a search term. We hope PSL is a superset of ICANN’s list; new TLDs are being added by Gerv to the PSL (.wed is the only one asking for substructures). ICANN ruled that you can’t have A records at the top level (can’t have “amazon” as a domain name). That means that we can issue certificates for *.amazon and www.amazon. You can’t issue a certificate for *.com, and we wouldn’t want to issue for *.foo in general, unless it’s owned by a company like Sony or HSBC. So top half of PSL is no longer populated with un-wildcardable names. Maybe we should initially block anything in the top list, and if the company could prove that they own the entire domain name, then we give it to them.

Regarding the PSL, there’s been no more progress in the IETF. There was a “dbound” BOF was held but no one has suggested a working group be formed.

Day 3 -Wednesday, 18 June 2014

NIST 800-52. Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations

(Prepared by Robin Alden)

Ben recapped http://www.nist.gov/manuscript-publication-search.cfm?pub_id=915295 “Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations”

Ben pointed out that it prohibits (for Federal Agencies) hybrid certificates. A hybrid certificate is one where the public key in the certificate is for ECDSA but the certificate is signed using RSA/SHA(2), or vice-versa.

There was a discussion over whether we could evaluate how well a server meets the requirements of NIST 800-52 (or some other acceptable standard) using a tool such as the Qualys SSL Server Test and perhaps not issuing an EV certificate unless server gets a grade A. The mood was that this was not palatable.

What is an SSL Certificate and Scope of Baseline Requirements

(Prepared by Doug Beattie)

What is an SSL Certificate and Scope of Baseline Requirements?

• What do the BRs cover?
• What should browsers accept?

This discussion assumes we are talking about SSL certificates issued under publically trusted CAs only.

Why is this an issue?

• BRs apply to any certificate intended to be used as an SSL cert: This is a badly stated assumption
• Some certificates are not intended to be used as SSL, but “could” be used.
• How can we limit proper client validation of SSL certificates to only those that are intended to be used as SSL certificates?
• What we need is a clear definition of an SSL certificate that can be used by the browsers vendors so that they trust only certificates that are “intended” to be used as SSL certificates, and no others will be treated as SSL certificates.

The following should be the order of events on order to achieve the intended goal:

• Define what it means to be an SSL certificate
• Let browsers enforce it
• Put into BRs

What are some of the technical approaches we could use? The following sections go into more detail.

1. EKU: Can we limit the values in the EKU such that we can tell SSL certificates from other certificates that are not intended to be used as SSL certificates?
2. SAN: Are there values we can put in the SAN that indicate this is an SSL certificate vs. another similar type of certificate?
3. CAs: Can we obtain a list of those CA certificates (Subordinate CAs that directly issue end entity certificates) that intend to issue SSL certificates, and if so, would that help solve this problem?
4. CA Certificates: CAs may not intended to issue SSL certs, but technically they could.
5. Summary
6. Actions
7. Next Steps

1) EKU

What values can we consider putting into the EKU extension?

• If a certificate has Server Auth, then it’s clearly intended to be used as a server certificate
• But, if the SSL contains either of the following, it currently can (is/must?) be treated as an SSL certificate
• anyEKU: Device certificates often contain these and they can be used as SSL as part of their intended use
• No EKU: The EKU extension is not required, and if not present the certificate can also be used as an SSL certificate considering the other aspects enable that to happen.

The concept of requiring serverAuth goes against concept of anyEKU in the RFC.

• Is this accurate? Can we limit the definition of an SSL certificate within the BRs beyond what open standards may state?

NIST position on anyEKU:

• They have backed off on their original position.
• They let the certificate be used under un-intended usage or applications.

Needs to be a 2-front position. Some device certificates use anyEKU (government). The policy writers need to get around this concept which then evolves to device manufacturers. 800-52: anyEKU is not allowed.

This might be hard for some vendors to implement.

• IE might have a hard time knowing the difference between IPSEC and SSL since the same certificate processing rules might be used for both
• IE uses key usage and then a good value in CN or SAN.

2) SAN

SAN has been required in SSL BR certificates since the beginning (2012)

• That is a good indicator that the certificate is intended to be used as an SSL certificate (must have SAN, can optionally have a CN)
• Could a user put something in the SAN that a user added which was not intended to be used as an SSL cert/domain name?
• IP address or DNSname (only 2 types that are meaningful to SSL certificates)

Is this a true statement?

• No Certificates which are not intended to be SSL Certificates will have SAN values of IP addresses and/or DNSname.

It was not clear from this discussion if this would adequately address the issue, however it’s worth pursuing.

Random statement during the discussion: For non-public CAs there are long lived certificates which do not have SANs (MS).

3) CA Certificates

It was pointed out that if a Certification Authority had set up a Subordinate CA to issue client certificates only, it would not be constrained or audited. In this case, if the CN contains a domain name, then it could be used as an SSL cert.

• Can subCAs like this be technically constrained to not issue SSL certificates?
• This is placing requirements on CAs outside of the BRs and audit requirements, so it’s unlikely this could be supported.

Can we collectively identify all Subordinate CAs that intent to issue SSL certificates?

• Can we add something to CAs that intend to issue SSL certificates and only those CAs can issue valid SSL certificates?
• Could we put id-kp-serverauth in all BR compliant SSL CAs and then the browsers could use that to to assist with validation?
• This might be possible, but it would be a long time before all CA certificates were replaced, so this is not a good approach for the short or medium term.
• Not all CAs set up dedicated CAs to support the issuance of SSL certificates, which might complicate this

If we can’t add something to the CA certificates, is it possible to otherwise identify and mark the CAs which intend to issue SSL certificates and which are being audited?

• How do you identify a CA as being able to issue SSL certificates
• must be technically constrained or

publicly disclosed and audited against the baseline requirements )

• This would allow all other CAs to immediately be excluded from being trusted for the issuance of SSL certificates.
• If the SSL certificate is not issued by one of these CAs, then it will not be considered an SSL certificate. All of the CAs that are listed will be audited for compliance.
• Today the CAs are all actively collecting their CA certificates for public disclosure to Mozilla. Could these CAs be marked as treated SSL issuers?
• This would introduce a delay between the creation of a new CA and it being trusted (the time for all of the browser vendors to receive the new CA and to push it out to their browsers. What technical options are available?
• CT for SSL CA Certificates?
• Posting to a common repository?
• How to authenticate that the CA posting them is truly going to audit these CAs?

4) Summary

• Requiring an EKU of serverAuth is a good idea, but excluding other profiles goes against the intent of the RFC, and there are device certificates that might need to be treated as SSL certificates which need anyEKU or No EKU
• Requiring IP address or DNSname in the SAN is good, but that may not exclude all non-SSL certificates
• Disclosing and Auditing of all CAs that intend to issue SSL certificates would work if the technical issues associated with the distribution of new CAs can be performed efficiently and expediently

5) Actions

While this is what I had in my notes, I’m not sure this makes sense or was the consensus during the meeting. Looking for feedback from the attendees on actions.

1. Browsers should get together and discuss what makes a certificate an SSL cert? Kelvin, Ryan and Gerv and Geoff
2. The level of auditing could be based on sampling of certificates. If the CAs indicated that they did not intend to issue SSL certificates, then they would still need to do most of the BR audit, but if there were a lot of SSL certificates, it would be a full audit.

6) Recommended next steps

• No actions until we hear back from browsers.
• Once browsers identify what makes sense from their root store policies, then we can merge and incorporate into BRs as a common set of statements.

Review of NISTIR 7924 Reference CP

(Prepared by Kirk Hall)

The next issue on the agenda was a discussion of the latest release of the NISTIR 7924 Reference CP (“Reference CP”). Dean Coclin started by reviewing the Forum’s actions to date. He said Tom Albertson created a comparison table comparing the Reference CP with the Baseline Requirements (BRs) and made a presentation in Ankara. Tom stated that it would be useful to harmonize the Reference CP with the BRs, and pointed out that each time the Forum creates a new rule we may move farther and farther from the same vocabulary and structure as the Reference CP.

At the Ankara meeting, the Forum decided to create a Working Group (WG) to harmonize the Reference CP with the BRs, but to delay the WG until the next draft of the Reference CP was released, which was anticipated to be in a few weeks. At the next meeting in Mountain View, it was noted that the new draft was delayed, so the WG was not formed.

Dean noted that a new draft of the Reference CP was recently released, with over 300 comments, most from Federal PKI users, and proposed to convene a WG now.

The Forum then discussed whether the BRs should also be reorganized at the same time to make cross-comparisons with CPSs and the Reference CP easier.

Robin Alden asked if the BRs should be reorganized to follow the RFC 3647 CP format.

Ben Wilson said he thought the Forum had already decided no at Mountain View, but Dean Coclin said he thought that question would be left to the WG for its recommendations.

Iñigo Barreira noted that there are many gaps in RFC 3647 and the Reference CP compared to the BRs, which he had shown in an earlier comparison table.

Dean Coclin said the BRs can just say “no stipulation” where applicable.

Jeremy said he thought that at Mountain View that the harmonization project would be too hard. He also noted that he did a mapping and comparison table last year that we can use if we decide to do the project.

The Forum then consulted the Mountain View minutes, which said the Forum would not convert the BRs to a 3647 format, but the Forum would review Parts 4, 5, and 6 of the Reference CP and try to add the best practices there to the BRs.

Dean Coclin then proposed a WG charged with the following two related projects:

1. Review the Reference CP, particularly Sections 4-6, and develop recommended amendments for the BRs that would increase SSL security; and

2. Consider reordering the BRs and the EV Guidelines to match the format of RFC 3647.

The WG would be open to Interested Parties, and would make recommendations to the Forum on what to do.

Iñigo Barreira asked why the Forum always started with US-based documents when coming up with SSL security-related requirements, and stated that lots of ETSI documents address security concerns too.

Jeremy Rowley stated that was a good question, and proposed the WG also consider ETSI documents when considering new BR security requirements. Jeremy also noted that the existing Forum Security Guidelines came from initial WebTrust and ETSI security standards. The consensus of the Forum was for the WG to also review ETSI security documents.

The following Forum representatives volunteered to serve on the new WG: Jeremy Rowley, Robin Alden, Ben Wilson, Moudrick Dadashov, and Dean Coclin.

Dean Coclin asked what the next steps would be. There was agreement that a formal WG should be created using a Ballot according to Bylaws Sec. 5.3.

Jeremy Rowley, Ben Wilson, and Dean Coclin said they could follow up today with a draft ballot and circulate it for review, then post it to the public list for comment and subsequent voting.

Discussion of SSL Issues

(Prepared by Ben)

Dean: What are the issues with the Baseline Requirements that we want to discuss?

Kelvin: There are two areas that I want to work on clarifying. One was clarification around the parts of the certificate and verification and the other was that because Microsoft operates its own sub CA there are things that make it somewhat cumbersome when we’re both the CA and the Subscriber and we’re trying to work between different roots. The BRs assume certain rules that make it difficult for us to figure out the approach we should take when both the CA and Subscriber are in the same organization.

Dean: So you are going to submit something?

Kelvin: Yes.

Rick: On a related thing, we were going to talk about reaching out to server vendors.

Ben: That’s this afternoon.

Jeremy: Are the EV guidelines again on for discussion, because we never finished that one?

Ben: Yes.

Robin: What about Ryan Sleevi’s issue about delaying …

Jeremy: Yeh, that one.

Moudrick: I have one question–if the BRs should have their own OIDs?

Jeremy: That’s a topic that’s come up before–whether or not we should have a , you’re talking about whether we should have specific OIDs for …

Moudrick: No, no, no.

Jeremy: OV, EV, DV, …

Moudrick: No, there are special contexts …

Kirk: BR-Compliant

Moudrick: … where I need to show that this is BR-compliant. And I want to use …

Moudrick: There is a way …

Jeremy: But you don’t have to …

Rick: There is one for DV and one for OV.

Moudrick: No, no.

Ben: Or for all you just use the …

Iñigo: What he is saying is for the document.

Ben: … higher …

Dean: The whole BRs.

Moudrick: Yes.

Ben: … the document …

Rick: There are two OIDs.

Iñigo: No, but that is for the type of certificate you can use, not for the document.

Jeremy: Why do you need one for the document?

Rick: I’m not sure I understand.

Ben: We can assign one for the document …, but we don’t know why.

Kirk: Well, I was thinking earlier, if we had an OID that said, “this is an SSL cert,” sorry, this is slightly changing, but couldn’t the browsers use that, look for that OID? If we required that every SSL, every certificate intended for SSL had the OID in it? Now, it’s not going to stop or prevent people from violating it, they’re not treated as an SSL certificate in the browsers and applications and we discover later that it’s not BR compliant get your roots pulled out. So you were talking about policy enforcement through OIDs, this could be a real simple solution as to what is an SSL cert. It’s an SSL certificate if you put it in the new BR OID and it is not an SSL certificate if you don’t.

Wayne: It’s a BR compliant certificate if you put the OID in and the browser can make a policy decision if it’s there.

Kirk: Then if someone puts it in there but they aren’t BR compliant, then the browser can say, “your roots are out.”

Kelvin: But the reality is that even when we have, the CAs are not BR-compliant we still have this notion of government audit equivalency that we have to maintain for at least another two and a half years.

Kirk: So create a government OID.

Kelvin: So what I’m really saying is that we won’t be able to make any real change effective on the use of these OIDs.

Kirk: But start a process now, and then in two years.

Eddy: Then disallow those that don’t have the OID.

Kirk: Right.

Kelvin: Where I think we would want to go is that for any CA that can’t show they are meeting the BRs they shouldn’t be allowed to issue SSL anyway, so they waive their privilege of issuing SSL server certificates.

Kirk: It’s an assertion by the CA as to whether this is an SSL certificate or not, and then you can police it later on and say, “you put it in there” or a government OID.

Kelvin: But there is already an EKU that indicates whether the certificate is serverAuth, and our policy is that any serverAuth certificate issued under publicly trusted roots should be under the BRs.

Eddy: Must be BR-compliant.

Kelvin: Right, so having an additional OID doesn’t really buy us much.

Unidentified: But you’re allowing the anyPolicy policy.

Kelvin: But that’s a different issue. We can certainly make a change to our product and make sure it looks for a certain EKU in certificates, but we don’t need a policy OID to do that.

Moudrick: At least as a first step, I think you have an OID and it makes sense to see if anyone is using it for indicating the SSL .

Kirk: When you guys work together are browsers when you work on a solution, consider a policy-based one or add an OID that the application looks for. I’m not saying override your policy about any of the other stuff, but it sure would be a way an application could know this is intended to be used for SSL. If the OID is in there, it is, and if it isn’t, it isn’t and then your browser can treated it differently. If someone violates the rules by claiming it is for SSL, and you find out later on that it was not under a BR compliant CA, then you can punish that CA appropriately.

Kelvin: Let’s say there was a CA that issued a certificate with a serverAuth EKU that could be used for another protocol. So the customer comes to that CA and they don’t tell you what it’s for, all they say is, “I want a certificate to use to authenticate my server,” what OID would you be giving them to use with that certificate?

Kirk: I would not give them an intended-for-SSL OID.

Kelvin: But you’re doing the same thing–you’re verifying a domain name, etc.

Kirk: Let me put it this way, if I’m BR-compliant, I may as well give them an SSL OID, but if I’m not BR-compliant, I shouldn’t give them the SSL OID.

Kelvin: If they come to you and you give them the SSL OID and they’re IPSEC, whatever, how does that help me as the relying party distinguish the use of the certificate between those used for SSL with those used for something else?

Kirk: When you say “me as the relying party” you mean Microsoft?

Kelvin: Microsoft software. We’re trying to interpret based on that OID, whether that certificate is being used as intended or being used for something else.

Kirk: I guess I would flip it around, Kelvin. You can only put the SSL certificate OID if you’re BR-compliant and if the certificate is BR-compliant.

Eddy: But everybody must be BR-compliant that issues SSL certificates, according to Kelvin. So he doesn’t need to look at the OID, because he knows the CAs that issue these certificates are BR-compliant.

Kirk: But we know that CAs have a side business of issuing, but I don’t know if all CAs who are BR-compliant, but I thought that some CAs wanted to reserve the right to issue non-BR-compliant certificates because they are not intended for SSL. All I’m saying is why don’t you put a marker in each certificate that will tell you … ?

Kelvin: I think we want to phase that out.

Rick: We don’t have a market in this, but the downside of what you’re proposing is … Well, the customer doesn’t tell us what they’re going to use it for. We don’t ask. What happens a lot, or what we’ve seen in the last year or so, is that the customer gets it for an IPSEC server or they get it for some PCI devices that communicate over the public internet back to some server, and we issue them a certificate–an SSL cert is an SSL cert is an SSL cert, and this one works. They come back to renew and say, “It works. We want exactly the same thing. We want a 1024-bit key, …” And we say, “sorry, we cannot give you a certificate for a 1024-bit key.” And they say, “well, why not? That’s the only thing that my devices support.” And we say, “well, the browsers or the CA/B Forum told us we cannot issue them.” And the customer says, “what business is this of the browsers? I’m not using my certificates with a browser.” So we’re trying to be more conscious of how customers are using certificates and get customers to self-identify whether they are using their certificates with browsers. So if you’re not using your certificates with a browser, go here, because otherwise you are going to be subject to future requirements that get passed down by the browsers that may not be in your best interest.

Kelvin: So are there other issues that come up related to the BRs? What other problems have the BRs generated for CAs?

Jeremy: SHA2 would be one, if it ever became part of the BRs.

Rick: Well, if it never became part of the BRs, by January 1 2017 we have to stop selling SHA1, for the public roots at least. So what we’re going to do is come up with other roots that we can issue SHA1 off of.

Jeremy: But if you have someone who has embedded your roots into their hardware, it becomes very difficult to resolve.

Rick: The only saving grace is that in many cases these are all devices chaining up to one of our 1024-bit roots, which themselves are being pulled from the browsers, and once they’re pulled out of the browsers they are not public roots anymore, and we could issue 512-bit MD5 certificates, if that is what the customer needs.

Kelvin: That same root is trusted by that ecosystem and by browsers, that’s the reason for the problem, right? Once you separate those two ecosystems you eliminate the problem.

Rick: Right. You’ve been in the business a long time. If you go back 10 years, there wasn’t the distinction between used by browsers and used by everybody else,

but now there is. So now I’m trying to pull those two markets apart and separate them.

Kelvin: For Microsoft, we are not trying to separate the browser use case from the other use case because we run a program for the operating system. So any SSL client or TLS client uses an SSL certificate that is part of our program and whatever policy changes that we push out reflects across all of these scenarios. So, from our point of view, we actually don’t want to separate these use cases into distinct things. I understand we are the exception, though, but we have an OS to run.

Jeremy: Another scenario is that some devices require a MAC address in the CN field, which is not permitted in the BRs.

Iñigo: What scenario is that?

Jeremy: Well, it is for device-to-device SSL communications.

Kelvin: It’s signed SSL obviously?

Jeremy: Well, what is an SSL certificate?

Kelvin: Does it have serverAuth EKU?

Jeremy: They might use a different EKU.

Kelvin: Could they use another EKU that I don’t care about in my root program?

Jeremy: They might be able to use a clientAuth EKU.

Iñigo: If the BRs are not only for SSL, then we have to acquire an SSL for websites, and an EKU for authentication or private authentication.

Rich: What do you mean?

Iñigo: Gerv was saying yesterday that we would like to have a clearer definition of what an SSL certificate is and what it can be used for. So, we were talking about putting the BR OIDs in your certificate. It is technically very easy to put multiple OIDs in your certificate. Your own OID, the ETSI OID, the CABF OID. It’s easy and I’m only using those three in my SSL certificates. That we will review in the audit, and it’s not a technical issue. If there are certificates that are being used for an SSL or TLS connection you can create another root, and it’s not publicly trusted. But if they want to do this, then the solution is to define exactly what an SSL certificate is and they need to check to see if it the same key usage or extended key usage for your customers. If they are the same, then we’d need another mark, another key usage, or way to distinguish them with different profiles.

Kelvin: So it sounds like there are two broad classes of things that don’t quite fit in to the Baseline Requirements. Or rather there is one class of things that don’t quite fit in, and there is another class of things that we haven’t really talked about that I think should fit in, but based on what was said may be excluded. So the first case is people using legacy devices with a client and server where the client is not a browser and the server is some random device that they don’t update very often and they can’t meet current requirements. In those cases, the BRs basically force them out of the, or prevents them from getting certificates from roots that they currently trust, and if that’s the problem, I don’t know exactly how to deal with them unless I know how those devices behave. As I’ve said, there might be other mechanisms for them to opt out of the browser requirements, but I’d rather not use mechanisms that currently do not exist to identify browser-based SSL certificates. I’d rather use something that basically breaks those certificates that don’t meet the requirements so that they don’t show up and just don’t work with browsers, perhaps by using a foreign EKU that browsers don’t know about.

Rick: We’ve done that where we put in poison EKU that thankfully the devices ignore, but that doesn’t always work. In fact, I think there are three classes. One is the use of SSL certificates, but not for SSL. For example IPSEC Certificates which is an SSL certificate that is otherwise used for SSL, but also works for something else, an IPSEC server. Then, in the SSL group, there is SSL for use by browsers and SSL for use by other things. They could be devices. They could be mobile apps, smart phones, etc. Unfortunately when you get together with Gerv and start talking about what makes an SSL certificate, you’re going to have to take some care because your jurisdiction is really SSL for browser use. However, the guidelines we’ve been developing have gone beyond browser use.

Kelvin: I thought the Forum’s scope went beyond browsers to platforms. There was something about that, right?

Rick: It’s the CA / Browser Forum, but what do the Bylaws say? Do they say whether we’re concerned about SSL for browsers only, or for all SSL?

Ben: Moudrick’s assignment is to write that up.

Kelvin: But to your point, mobile applications in our opinion should follow the same rules when they come into a TLS endpoint. They should not be following different rules. So mobile applications, in our opinion, should be considered like, or the same way as, browsers.

Rick: Are they in scope? I’m not sure they’re in scope.

Kelvin: They are in scope if they are using publicly trusted SSL certificates. If they want to opt out of what we’re doing here, they can do their own root key management and manage trust, they can. That is the admin’s problem.

Moudrick: Today’s situation is quite complicated. There are historical certificates that somehow need to handle SSL. And that something, for them to be interpreted correctly and explicitly based on the content of the certificate, is the OID. So the proposal is that starting at this time you rely on the policy and this criteria.

Kelvin: I don’t know if that solves the problem. When we pushed out the SHA2 policy, I got feedback from CAs saying these cell phones and devices cannot do SHA1 and so that once the policy is implemented customers can no longer use these devices. But these will still be SSL certificates.

Moudrick: But they will not be using that OID, so it is out of scope.

Kelvin: The BR OID?

Moudrick: Yes.

Kirk: You put an ear tag on certificates – “I am BR-compliant.” You browsers can decide what you want to do, how to treat those certificates. Forbid people from putting the BR OID in any certificate that is not BR compliant. If a CA violates the rule and puts the BR OID in a certificate that is not BR compliant and you find out, you punish them. I’m just saying put a label or create a new label and then you guys decide the rules.

Jeremy: But there already is, we already have an OID. We have two.

Rick: There are two defined in the BRs. One for DV and another for OV or CAs can choose their own OIDs to indicate compliance. And there was much discussion about how it would be easier if everyone used the same OID, but we agreed and decided that CAs could do whatever they wanted. So we do put our BR OID in every BR-compliant certificate that we issue, and there are some rare cases where we know we’re not compliant with the BRs and we leave out the OID.

Kelvin: What if CAs have some leeway in granting exceptions? So for example, a customer comes to you and says “I know about SHA2, but I have old software and need MD5 and I just need this to work, and I need a 512-bit key, and I don’t care about security.”

Jeremy: The problem with that is it’s easy to make exceptions after you’ve issued the certificate. The relying party is the one affected by this. They have no idea that they are using MD5.

Kelvin: But part of the problem from the browser side, and hash algorithm is a very obvious example, there are probably examples that are more in the gray area, but at some point, browsers need to stop trusting certain algorithms certificates. For a 512-bit key, you can issue as many of those and they won’t be trusted by Windows. And in the BRs we say you must use a 2048-bit key or larger.

Jeremy: That is one of the reasons you have CAs, so that you don’t have to worry about programmatically distrusting any bad practice you’ve ever seen. You could say, “SHA2 is now required” and if you tell the CAs that, the whole Internet has to comply, instead of you having to go to each user and telling them “SHA2, SHA2, SHA2.” So I think that for public trust you want there to be a minimum standard that users can say, “I know this is publicly trusted, therefore I know it meets this criteria, and if it’s trusted by the browser, then I know that it is meeting the BR level of compliance.” If you allow CAs to make discretionary decisions, you go back to the Wild West where nobody knows what’s out there, and what they are relying on. I go to a site and get a 512-bit certificate because they convinced their CA to issue it.

Kelvin: And that’s our reason to push these things in the BRs first, up to the point where we can actually make the change in code to block something, and then go back and see where we go by doing that. But it would be possible for us to do that sort of thing.

Jeremy: But the nice thing about using this system that we have, rather than forcing you to go and do that, is that you can make sure that it happens without having to go back and update all of your older software. You don’t have to continue to support Windows XP for millions of years because it’s still being used, because none of the CAs have issued a 512-bit certificate, because they can’t off the public root. So I really

don’t like exceptions to the BRs because as a user it doesn’t tell me what I’m using, not as a CA but as a user, I no longer know what I’m relying on. With the BRs, I at least know I have some standard that I can look at.

Rick: I think that in 10 years from now this will have been sorted out. The non-browser uses will be issued off non-public roots. And that’s the way we’ll handle exceptions, so to speak. It’s just that …

Gerv: What he means is that roots embedded in browsers, CAs will avoid using them for anything other than publicly trusted SSL. Right?

Kelvin: And my point is that for Microsoft, it is not just the browser that uses the root certificate that I’m managing. It’s also all of the mobile applications, … for us it’s not just a narrow IE.

Rick: I’m thinking mainly of a customer with a PCI device. It’s not a Windows PCI device. I don’t think there is any such thing. They want what they want. And there may not be overlap with what we want for browser use.

Gerv: This is a device that talks over the internet via a server, but the device can have any such roots in it, which you do when the device is created. So it could easily have roots which are not the same as the publicly trusted roots.

Kelvin: We have a version of mobile OS that works with Windows and there are applications on it, and …

Rick: Does it come with an embedded trust list?

Kelvin: … no, the update mechanism works the same way unless the OEM that makes the embedded device disables it. So we manage it unless the OEM decides to disable it. It’s not a very clean separation.

Rick: Yes. That makes things kind of messy. If I take you aside for the moment, we are being a lot more conscious of this, and trying to make sure that any new devices won’t just automatically take our public roots and embed them. The problem has been in the past that few customers tell you that they are doing that. We all make our roots available on the website for anyone who needs to consult them and find out what they are, but people download the root packets and then embed them in some device. And we want to stop that as much as possible.

Jeremy: I like your poison EKU concept. That is what we did with the NFC Forum. Basically, it makes it so that browsers won’t trust them at all, but you can still use public trust so that they can chain to your roots in case they’ve already embedded them. They have very limited root stores. They can’t create a whole new root store like they can on new mobile devices, and that is why the NFC did it because we can’t create a whole new root store, but if we put in a poison EKU we can avoid public trust …

Gerv: When you say a poison EKU, you surely just mean an NFC EKU, don’t you?

Jeremy: A poison EKU just means that it kills it in the browser.

Rick: A poison EKU is a critical EKU. It is simply some new OID that they have not seen before, that therefore browsers should reject.

Jeremy: It’s the NFC EKU, but I say poison EKU as just a general term that I use because Google coined it as a poison EKU in CT.

Rick: But that relies on the browsers that will reject it, but the relying party device, or whatever, is so old that it doesn’t implement 5280 completely and so it doesn’t know that it needs to reject the critical EKU that it doesn’t understand, and there have been cases where that is true and cases where it is not true.

Gerv: But this is NFC …

Jeremy: But going forward, the new stuff you can actually use your roots as long as they recognize the EKU that is in there. That’s why tying the SSL cert, like Gerv was talking about, to serverAuth plus a series of other criteria because then you can easily avoid the whole “what is an SSL” issue by putting in an EKU that is not serverAuth.

Rick: I would like this clarified in the BRs, …

Jeremy: I would too.

Rick: … because I can imagine some who are not here saying, “No. Anything you issue off your public root has to be compliant.” [Unintelligible] Actually, Kathleen would say, “we care about, if it’s off the public root.”

Kelvin: Well, Mozilla cares about three EKUs. We care about seven, and there is a whole other universe of EKUs out there.

Gerv: We actually care about four. There is OCSP as well.

Rick: So, would you guys be in agreement? Would it make sense to come up with a new extension, called poison or not, that we say, “if the CA puts this in an SSL certificate that chains up to a public root, we know the browsers will never understand this EKU and they will reject it, but as long as the relying party software accepts such certificate, it is OK to issue these kinds of certificates”?

Kelvin: As long as the certificate does not contain the serverAuth EKU.

Jeremy: … or the anyEKU EKU.

Rick: Right.

Gerv: No, hang on there.

Eddy: “Any” would be acceptable.

Moudrick: “Should be”

Gerv: If the certificate contains the serverAuth but also contains another unknown critical EKU, the browser should still reject it, right?

Kelvin: Well, no. Our behavior would be that we would accept it.

Rick: Well, it doesn’t have to be an EKU, it could just be an extension.

Kelvin: No, we want something where existing software would break, but we would check the certificate, if you use something like that, but we don’t want to go back and patch 5 versions of Windows going back ten years.

Jeremy: And if you have one that knows and one that doesn’t know it will ….

Gerv: Are you saying that if Windows encounters a certificate with an EKU that it doesn’t understand, which is marked as critical, which I thought means that if you do not understand this then you are to reject the cert, but it has another EKU that it does understand, then it will just go with that?

Kelvin: Windows, if it sees an EKU that it understands, it doesn’t matter what other extensions are going on, it would trust the cert.

Rick: I’m not proposing a new EKU. I’m proposing a new extension. A new extension that we’ll say is critical and that by definition, no one understands it today, but that some new relying party that comes along might say, “that it is the extension that I’m going to look for in the certificate,” would it be acceptable to put it in the BRs that if you add that critical extension in an otherwise perfectly legitimate SSL certificate chaining up to a publicly trusted root, that is okay according to the BRs and it will be rejected by all known browser software? And that would be the behavior?

Kelvin: I’d have to review the behavior for Windows, but I think that should work for Vista and up.

Rick: So that would work in browsers and non-browsers because …

Moudrick: How is that different from the OID?

Kirk: You can either make the assertion it is BR-compliant or it’s not.

Rick: The difference, Kirk, is that what you suggested is let’s make up a new OID that means “you’re in, you’re an SSL certificate.” Your certificates are covered by the BRs. What I am trying to carve out here is the exception, the opposite of that.

Gerv: It is an exclusion mechanism, not an inclusion mechanism. The thing about doing the OID is that …

Moudrick: This should work if we assign a new OID to the BR. It could say this is not a BR certificate. That way, DV – OV has a unique OID, but the BR OID says this is not a browser-oriented SSL certificate.

Kirk: I thought the BR OID did say it.

Ben: You could do a negative BR OID.

Rick: A “non-BR” OID.

Moudrick: It’s a BR that excludes DV and OV that is not intended for browser use.

Jeremy: Yes.

Rick: That’s what he’s proposing.

Gerv: But the BRs are all about browser use.

Rick: But Kelvin says it is for his entire ecosystem. All SSL certificates consumed by anything in his ecosystem are covered.

Wayne: Do you think your proposal … I understand that the idea is that this solves a legacy problem where you can’t go back and modify the legacy clients. Is that the best approach going forward, to encode it in the BRs? It might sound good now because it solves a legacy problem, or does it?

Rick: My point is that it would cover the next few years until we can get to the point that we can get these customers to identify themselves up front that they do not want to use these with a browser or something else in the ecosystem. .

Wayne: Well, the kind of OID that these guys are describing …

Rick: No, I think the long-term solution is a totally separate root group that does not appear in the browser.

Jeremy: I think that if you are creating a mobile, something to run on mobile, where you already have a root store, you don’t have a whole lot of space, and you don’t want to throw in a whole new set of roots. I guess you just want them to go and get them to comply with whatever the current BRs or CA/B Forum policies are.

Wayne: I think there is a useful case, like where you want a MAC address in the certificate and it’s not BR-compliant for a technical reason that’s valid. So there should be a way going forward, and maybe requiring serverAuth is the answer. To have a documented way for some of these groups out there creating new SSL applications to do it in a way that doesn’t impact the BRs makes sense. I’m not convinced that the poison extension is the right way. It doesn’t make sense to me going forward like the way it makes sense to be me as a legacy solution.

Ben: It also seems to me that somebody else would have already talked about it. We could look to see if anyone in PKIX has said and whether they decided yes or no that this was a good idea or not. ,

Rick: I haven’t heard anyone talk about this.

Ben: I sort of like the idea of a negative OID, and I’ve also wondered about a “test” OID, too.

Ben: A policy OID.

Jeremy: A policy OID that you put in the extension that Rick was talking about?

Ben: No, not an extension, it would be a non-critical policy identifier.

Rick: For this idea, rather than use an existing extension …

Jeremy: .. you need serverAuth.

Ben: I was thinking that if you want to have something for going forward, and you don’t want to break other things, if there is legacy software that you want to protect, you could do anyEKU is for these other devices without the serverAuth, but if it does have the serverAuth, then it does have to have this OID.

Kelvin: Wouldn’t that open up these to attack?

Ben: Yes.

Rick: So, anyway, I’ll think about formalizing this and proposing this to the list.

Wayne: It seems that this would fit in with our effort to come up with a proposal for the definition of an SSL certificate, and we could ballot this altogether.

Rick: The anti [inaudible] … CPS ..

Kelvin: … still going to use SSL for …

Jeremy: “SSL for non-browsers.”

Kelvin: That’s the thing, what to call it.

Multiple: You could just call it Baseline-exempt … SSL for … the extension SSL certificates … BR-exempt,

Rick: And it might not even be for SSL. What about SMTP and IPsec?

Ben: But I think we would want to define a different profile, but not necessarily different vetting, authentication, etc.

Kelvin: Obviously, certificates for SMTP would have to meet the Baselines. There is no reason why they would follow separate rules, unless the software is old.

Rick: Yes, the software is old, and the argument I’ll get from customers is, “what right does a browser have to dictate what I put in my certificate”.

Kelvin: But that certificate chains to a root CA certificate that is in the OS, therefore ….

Ben: … Moudrick’s issue .. and even though it’s OS and this is the CA/Browser Forum, because it’s so intertwined … SSL certificates that are issued for servers.

Gerv: Well, OSs down from here: Linux, and Mail, and then Gecko, and then HTML, and there is no other OS … Mozilla.

Rick: And this is tied to the afternoon discussion.

Ben: And this is the first time I’ve heard this argument raised.

Rick: Unless we invite the mailserver vendors to the party …

[ ]: … root store …

Gerv: Well …

Rick: … and craft standards that enforce them, it seems grossly unfair to propose standards for a certificate that they use for their products and then their customers contact us with their problems.

Kelvin: What specifically would break, given the BRs that we have? What things don’t work with that?

Rick: I don’t have a specific example, but it could be, “my mail server is very old. It cannot handle a 2048-bit certificate or a SHA2.”

Kelvin: Then arguably they shouldn’t be using those servers because they provide no protection.

Rick: The customer might say, “I use them internally. They’re safe because I use them internally and they are not accessible from the outside”

Ben: Then I think we need a profile for that kind of thing.

Project Lifecycle Revision

(Prepared by Robin Alden) Moudrick led this discussion.

There is no clear statement of the goals/mission/scope of work of the Forum:

What are the suggestions?: defining ev or security requirements and practices of CAs or something else?

In the past we have had, and we should have, a workflow where we have a separate page for ‘issues’ For new items – we register an ‘issue’ When we go to ballot, then we should be able to link back to the issue that was raised that led to the ballot. Maybe we need some type of issuing tracking mechanism?

Certificate Transparency

(Prepared by Robin Alden)

(11.19am Wednesday) Kirk suggested that the complexity of CT looked to be still increasing. It is not yet clear what we are required to implement. Is the CABF to run a log..? [unanswered]

Gerv suggested that the publication of the content of the Google log server would be a public service.

Mozilla and MS have no plans to implement CT, but are both watching with ‘interest’

Bylaw Changes

Jeremy suggested that we perform tasks outlined in the IPR Policy in order to ensure enforceability and future compliance. Ben agreed and said that he would send out the required notices of guideline adoption. Jeremy also noted that wee need to convene a Patent Advisory Group to review the list of excluded IP originally submitted when the IPR policy was adopted.

OCSP Stapling implementation and TLS 1.2 by Servers and Crypto Improvements

(Prepared by Rick Andrews)

We discussed how to get OCSP stapling more widely deployed. No one CA can do this; should we divide and conquer?

The idea is to reach out to non-MSFT server platforms to support OCSP Stapling and enable it by default.

Kelvin says there are two problems:

1. server vendors and load balancers (no stapling support there)

2. getting customers to enable

Iñigo asked why do we care? Do customers care? We want to get to hard-fail, and this is the easiest way to get there. Also, it enhances privacy

We should get rid of BR language that says you can eliminate AIA if you staple. If the AIA extension must always be there, then the web server needs no other configuration to enable stapling. One just needs to open the firewall. We need a ballot for this.

Iñigo said that Cisco’s latest products don’t support SHA-1 and 4096-bit roots. Kelvin said he could try to work with Cisco to change that.

We could just push our customers to adopt stapling, and get them to push back on server vendors

Why push stapling? Performance gains. Why push must-staple? Heartbleed and prospect of hard-fail

Rick explained the Web PKI Ops survey and the lack of server response

Mozilla paid to get stapling added to openssl, but it’s off by default. If we wanted it turned on by default, would that be in openssl or in Apache modssl? Need investigation. Gerv might know someone in Mozilla who has standing in Apache; Ryan Hurst has contacts at nginx but they refused to turn it on by default. Robin asked if they fixed that startup issue?

Rick to reach out to big iron vendors and ask them to support stapling. Robin/Rob Stradling and Gerv/delegate and Doug/Ryan Hurst will try to get Apache/nginx to enhance support

Does openssl have the ability to make an http call and process response (to get the OCSP response from the CA)? No one knew. Gerv said OCSP stapling is supported in modssl, but it needs a cache (mandatory) and there are three types of session caches, some of which require specific modules.

If we’re successful, what else could we do with server vendor contacts? Wayne suggested preferred ciphersuite ordering, TLS 1.2, validate certificate chains upon startup, what else? Multi-level stapling? Kelvin thinks its easier to have the browsers support intermediate certificate revocation via CRLSets or equivalent.

Optimizations could come from NIST document or other places

Response would probably be “go ahead and write the code”, but who would be able to do that?

Planning for Future Face-to-Face Meetings

September 16-18, 2014: Richard at WoSign in Beijing China, need to distribute the invitation letters and start the visa applications

Feb/March 2015: Microsoft will look into hosting. Digicert (Utah/Salt Lake City) will be the fallback

May/June 2015: SwissSign, Zurich Switzerland

September 2015: eTugra in Istanbul Turkey, or Izenpe in Bilbao Spain as backup

In 2016 we are looking at Asia-Pacific, U.S. East Coast, and then Europe. DigiCert or Microsoft are possible candidates for the US meeting.

List of tasks

Wayne and Gerv will work on a Bugzilla-based issue tracking system that we can take a look at in Beijing.

Adjourned

The group then adjourned, expressing great appreciation to StartCom and Eddy Nigg for hosting this face-to-face meeting in Eilat.