2015-08-20 Minutes
Minutes of August 20, 2015
Attendees: Atsushi Inaba, Ben Wilson, Billy VanCannon, Bruce Morton, Cecilia Kam, Davut Tokgoz, Dean Coclin, Doug Beattie, Eddy Nigg, Jody Cloutier, Kirk Hall, Li-Chun Chen, Mat Caughron, Patrick Tonnier, Sakib (Microsoft), Stephen Davidson, Tim Shirley, Tim Hollebeek, Tyler Myers, Vicky (CNNIC), Volkan Nergiz, Wayne Thayer
Antitrust statement was read by Dean
Roll Call completed
Review Agenda: No items added
Approve minutes of August 6, 2015 meeting: Minutes approved. Ben to post on website.
Ballot Status: Domain Validation: Kirk said they are working on a new draft in the Validation WG. IV OIDs Ballot 150: Jeremy revised the ballot to include EV OIDs. Kirk suggested that the term “IV” be defined in the BRs.
Microsoft Root Program Updates: Transcribed from the call:
Wayne: I believe the concern from Rob Stradling was that the new driver-signing portal for Windows 10 requires you to sign a piece of code to authenticate with the portal, and I haven’t done this, so I may not be using the right terminology. Rob’s testing has indicated that doing so requires you to sign with a specific Symantec code-signing certificate, and it doesn’t support other CAs. That is based on his experience and the error that he gets returned. That was his primary concern. His secondary concern was that some of the language on the portal indicated that only Symantec EV code-signing certificates are supported on Windows 10, but I believe Jody answered that by saying, you tell us what you would change there, but the question around authenticating to the portal with the Symantec certificate is still open, as far as I know.
Sakib: Jody didn’t have the opportunity to plug me into that conversation, but I’m sort of aware that we have asked for EV – but we have raised the bar requiring what you need to sign and use the portal. We have restricted it to an EV certificate, but I’m not entirely aware of whether we restricted to a particular CA or whether any EV certificate will do, but I guess the concern is that it looks like it’s only a Symantec certificate.
Dean: Actually Jody said that that was not the case, and that it was supposed to work with DigiCert and Comodo, but when he tried it with Comodo, apparently it didn’t work.
Ben: DigiCert’s EV code signing certificates seem to work.
Sakib: Someone reported a bug. It looks like Symantec and DigiCert worked, but which certificate was not working, if there was a bug with a Comodo certificate, it looks like all three CAs were supposed to work, but perhaps we’ve found a bug, so I’ll follow up. If there is an issue, please forward it on to me.
Wayne: So I think Jody did refer us to Sakib for a couple of SHA1 questions that Doug and I have been asking.
[Jody joined]
Dean: Jody, we’ve been discussing the Comodo thing with Rob Stradling and the fact that the Comodo certificate was not working. You said last night that we need to update text, but Rob came back this morning and said that it failed.
Jody: I added a few of these manually to the portal, so I’ll need to look at it to see whether that particular certificate has been added to the portal. So if it is not working, that may be the reason.
Dean: I would suggest at this point, since Rob responded to your email this morning, and since none of the Comodo people are on the call today, maybe you can just respond on the list as a way of saving that dialogue.
Jody: Also back in April, Microsoft sent out a communication that gave instructions on how to enable certificates to work with Windows 10.
Dean: Next is the SHA-1 question.
Wayne: There is a statement in the Microsoft root server requirements under the code signing section that says that all OCSP responses after January 1, 2016, must be SHA-2, and there’s a lot of confusion what that means. Does that SHA-2 response apply to SHA-1 certificates or only SHA-2 certificates?
Doug: What we are trying to really uncover is do we have to go back and modify our existing SHA-1 infrastructures which could possibly break relying parties that are relying on certificates valid into 2016, which is a completely compliant certificate that expires in 2016 and should be trusted. We don’t want update our systems for the requirements and all of the sudden break potential custom implementations that are using SHA-1 and can’t do SHA-2, either as the hashing algorithm on the OCSP message or on the OCSP signing certificate. For OCSP signing certificates, we’d like to continue to use SHA-1 for SHA-1 hierarchies and using SHA-1 on OCSP messages, and we would like to confirm that is the case.
Sakib: Jody forwarded the questions which we discussed internally, and I hope I can answer your questions today. The first point was the confusing the data and apparently the question was that we said you need to start issuing new OCSP signatures after January 1, 2016, and there was also a question what Windows behaviors were going to be. The Windows behavior is based on the presence of the must-staple extension in the certificate. So, if the certificate has the must-staple extension, then Windows will enforce after 1/1/2016 that the OCSP response must be SHA-2, and it’s only for the must-staple extension, and that will only be enforced on up-level–on Windows 10, and we won’t enforce it downward on older clients. So that should help mitigate the compatibility concerns. On Windows 10 we do have SHA-2 support, so does that answer the question?
Wayne: So that implies that CAs for the indefinite future can continue to expect SHA-1 requests for OCSP and return SHA-2 OCSP responses or a SHA-1 OCSP response, but SHA-1 is basically not being deprecated out of OCSP except with the must-staple extension. So flipping that around, if you’re not using the must-staple extension, do CAs need to make any changes to SHA-1 for OCSP ‘s either in 2016 or 2017?
Sakib: We’re not enforcing that behavior. The expectation is that that continues to work because we do have that down-level concern. We do want to start encouraging CAs to move to using SHA-2 for OCSP signatures with SHA-2, but we recognize that we have to handle the down-level problem.
Wayne: I’m not sure I understand the down-level problem, because outside of kernel mode, SHA-2 is supported in all supported Windows operating systems. I’m more concerned about the SSL certificate case than the code signing case, that’s where I think we’re not clear on what the requirements are for OCSP stapling.
Sakib: The enforcement is that it will only be based on the must-staple extension, but I can see where the language might be confusing, so Jody and I will take a look at it. We’ll focus on the OCSP signatures without the must-staple extension.
Kirk: Wayne, is it fair to say that it is CAs’ opinion that as long as there are SHA-1 certificates out there we would like to be able to continue signing OCSP responses with SHA-1, is that our ask for Microsoft?
Wayne: My ask is just clarity. I think it makes sense that if you’re serving up a SHA-1 certificate that you would find the OCSP response using SHA-1. The other piece of clarity that I’m hoping to get is that hashes are used within the OCSP request and response beyond just the signature, and it’s unclear to me whether a move to SHA-2 would require both the signature to be SHA-2 as well as the certificate identifier hashes in the in the request and in the response. So will Windows start sending SHA-2 certificate id hashes and expect the response to contain SHA-2 hashes? So it is a bit more complex than just the signature.
Sakib: The enforcement is going to be on the signature. The other statement that we’ve made is that we won’t actually deprecate OCSP certificates, or CRLs for that matter, because we don’t consider SHA-1 OCSP certificates or CRLs to be a problem because there is no input from the requester, so they aren’t susceptible to pre-image attack. But the concern with signatures is that there is some requester input that gets authenticated. So it is only on the signature that we’re getting back in the response that we’re doing enforcement on.
Wayne: So, excepting use of the must-staple extension, the signature can remain SHA-1. And, even in the case where you have a must-staple extension and the server fetches the certificate, as long as the signature is SHA-2, the other hashes in the OCSP request and response can be SHA-1. That really helps a lot, and I think it would also help to get that clarified in the documentation.
Sakib: The documentation can be made more clear. The enforcement is going to be must-staple-based. I tend to agree that in general for SHA-1 certificates you can send a SHA-1 response and for SHA-2 certificates SHA-1 is OK for the non-must-staple case.
Wayne: Then I would say that I assume the same thing applies for CRLs but I’d request that you call this out.
Sakib: I think we may have already said that but we can definitely clear that up for CRLs.
Wayne: The final request that I have is it would be great if there is a way configure a Windows system to behave the way it’s going to be in 2016 and 2017. Is there a way that you can publish something, a testing protocol that we can use for CAs to make sure that all of our systems are working?
Sakib: Sure, I’ve actually been working on a little document that I’ve been circulating internally in Microsoft with just a few other teams. I can share that document as well assuming Jody says yes, and that will allow you to simulate the behavior on 1/1/2016. Right now it is just for simulating the code signing enforcement. The must-staple extension behavior still needs to be coded up, but right now you can simulate the code signing behavior that we’re looking to turn on in January today.
Wayne: What about the SSL behavior for SHA-1 certificates?
Sakib: The infrastructure does exist, but it is not in my document. I would have to add it. I’ve deferred that until next year. It works largely the same way.
Doug: Just following up on Wayne’s first topic. We talked about SSL certificates and OCSP at that level, but it also is a potential question at the root level where we have SHA-1 roots. These SHA-1 roots are trusted and sign SHA-1 and SHA-256 subordinate CAs, and we need to know about how the signature is expected to be on OCSP responses, CRLs, and associates messages from the root CA level. In 2016 will they continue to be permitted, and in 2017 will they continue to be trusted, or will it be a point in time when they also have to be SHA-2?
Sakib: Roots will be treated the same way as other certificates. So if you have a SHA-1 root, the OCSP responses and CRLs will continue to be SHA-1. There is nothing special about the enforcement that we’re doing depending on the level of the certificate in the PKI hierarchy.
Doug: It would be good to also clarify that–with the technical things you’re doing and also programmatically with what Jody is doing about the rules and to ensure that the rules are consistent with the technical enforcement.
Wayne: Rick isn’t on the line, but there was another set of questions around time-stamping, that I don’t fully understand, but it has to do with the fact that SHA-1 hashes are used 3 or 4 different places with a timestamp. I don’t know that I can represent questions on the call, so can we forward those questions as well?
Sakib: I think those questions made their way to me. They had to do with the EFS Certificate and the EID field in an RFC 3161 timestamp. We did an internal review to see how we handle the code, and our take is that in Windows, we don’t actually use that attribute anywhere. We don’t make any security decisions based on the value encoded in that field. We also don’t expect things to break based on what that value is.
There was another question that I haven’t had a chance to look into about how the timestamp should be implemented on the server side. The question was that Windows behaves this way, but if I would like to make the timestamp that actually works for not just Windows but other platforms, what would be the best way to implement that? That question was with me. So I can get back to that, unless people had other questions about timestamps.
Wayne: If it would be possible for you to post that information and get it to Jody and get it posted out to the mailing list so that everyone can see it, that would be great. Thanks.
PAG update: Ben said the PAG approved their scope of work as proposed by Scott Petersen (Google): “The proposed revision of BR section 3.2.2.4 has highlighted an aspect of the patent policy related to a requirement that can be fulfilled by one of an enumerated list of alternative methods. The PAG will seek to develop a common understanding of how the patent policy applies to such a requirement. The PAG will also seek to determine if there is any shortcoming in what the policy does that should be addressed. The PAG may develop one or more proposals for actions that the Forum might take. It is out of scope for this PAG to evaluate the applicability of any particular patent to any Forum documents. If it becomes apparent that such analysis would be desirable, such activity could be conducted in a newly scoped PAG.” Kirk commented after a disclosure of an essential claim, it’s fairly unclear what the person making the disclosure is supposed to do and that the PAG wasn’t going to figure that out. He suggested that the patent owner should have the responsibility to do so.
Cert validity periods: Kirk sent out a matrix of the different options that came out of the F2F meeting in Zurich. This was discussed in the validation working group where many different opinions were presented. A consensus which seemed to emerge is that it didn’t make sense to reduce EV validity timeframe further and perhaps we should increase it to 3 years to match DV and OV. The WG will finalize their recommendation shortly. Eddy said there are much less EV certificates used so it’s easier to switch them out if there were a problem. Hence there shouldn’t be objections to raising to 3 years. Ben said Digicert would like to see all the validity periods to be the same, no matter what the length. Bruce also said they prefer 3 year EV. He also asked about the re-validation timeframe. Wayne said we need to attack one piece at a time but also said the validity period of the data is more important than the validity period of the cert. Kirk asked if there were any objections from those on the call about changing EV to 3 years. Mat from Apple said his colleague Geoff may have some issues with that. Kirk said the Validation WG will put something out on the mailing list for discussion.
Working Group Updates: Code Signing: Some comments were received and will be reviewed at the next WG meeting. Another draft will be provided after that.
Other business: Davut said he has confirmed the Crowne Plaza as the hotel for the meeting in Istanbul. Everyone who is coming should state on the wiki their arrival/departure dates and number of nights. He also posted a link for the electronic visa which is required for most visitors to Turkey. E-Tugra will host a dinner on Weds night on an evening cruise. Final hotel rates will be posted shortly but expect to be between $150-175 per night plus tax. E-Tugra will book the hotel, please do not book yourself as they have guaranteed a certain number of nights for the conference to get the special rate which E-Tugra must book.
Next Teleconference September 3rd.