[cabfpub] Allowing SHA-1 OCSP and CRL signatures past 2016
rob.stradling at comodo.com
Thu Oct 27 13:41:23 UTC 2016
Is this only a problem for kernel mode code signing? Are certificate
revocation checks even performed for kernel mode code? (IIRC revocation
checks can't be performed for kernel mode code loaded at boot time
before any network driver has been loaded, because it's impossible to
reach any CRL/OCSP servers at that point).
Hmmm...perhaps it's not just kernel mode. I just found this:
https://support.microsoft.com/en-gb/kb/2763674 (although I don't see any
mention of supported algorithms for OCSP)
What happens if a problem Vista / Server 2008 machine tries to consume a
SHA-2 OCSP response? Does it fail silently? Or does it showing a
warning but allow you to proceed? Or does it refuse to run the code?
Possible technical solution (that wouldn't require continued issuance of
SHA-1 OCSP responses / responder certs):
Starting with Vista, Windows revocation checking typically checks OCSP
first but if "none of the OCSP URLs in the authority information access
extension succeeds, then fall back to using CRLs"
Have you tried getting your OCSP responder to return a "tryLater" or
HTTP 404 response when the HTTP User-Agent in the request indicates that
the client is Vista / Server 2008?
Hopefully doing this would trigger the client to download and verify the
CRL instead. And as somebody already pointed out, the BRs don't yet
prohibit SHA-1 signatures on CRLs.
On 27/10/16 13:58, Rick Andrews wrote:
> Vista and Server 2008.
>> On Oct 27, 2016, at 3:19 AM, Rob Stradling via Public <public at cabforum.org> wrote:
>>> On 27/10/16 09:05, Gervase Markham via Public wrote:
>>>> On 26/10/16 21:40, Wayne Thayer via Public wrote:
>>>> Moreover, without formal approval of this rule change, every CA that
>>>> wishes to maintain SHA-1 OCSP signing capability is left with a
>>>> dilemma - do I assume the ballot will eventually pass, or do I cram
>>>> in a ceremony to create a long-lived SHA-1 responder certificate
>>>> before the deadline?
>>> Would a straw poll help to ease that fear? But three browsers already
>>> support this, and I can't see many CAs opposing it.
>> Please could we first establish precisely _why_ any CA needs to sign any
>> further OCSP responses or OCSP responder certs with SHA-1 ?
>> [See my question to Rick about old versions of Windows]
>> Depending on Rick's answer, I may have an alternative technical proposal
>> (that won't require further SHA-1 signatures).
>> If it turns out that there's no actual technical need for this ballot,
>> then I oppose it.
>>>> I accept that neither of these reasons amount to a crisis worthy of
>>>> throwing the Forum rulebook out the window. I do think that the
>>>> discussion has been helpful in highlighting what might be an
>>>> inconsistency between the bylaws and the IPR policy, and to serve as
>>>> an example of the problem with having a 50+ day balloting process.
>>>> The current situation is unique, but I'll be surprised if it's the
>>>> last time that we're looking for a way to "rush" through a ballot.
>>> Quite so. See my points earlier about perhaps updating the process so
>>> the formal vote happens beforehand, but the change is held in abeyance
>>> pending the completion of IPR review. That way, CAs can at least have
>>> certainty about what the vote result is, even if they don't have
>>> certainty about what an IPR review might turn up.
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> Public mailing list
>> Public at cabforum.org
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
COMODO CA Limited, Registered in England No. 04058690
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
More information about the Public