[cabfpub] Allowing SHA-1 OCSP and CRL signatures past 2016
Rick_Andrews at symantec.com
Wed Oct 26 14:27:06 MST 2016
Rob, I think the primary use case is OCSP for code signing certificates (and
the ICAs that sign them) that sign code that is validated on older versions
of Windows that do not, and will not, support SHA-2.
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Rob Stradling
Sent: Wednesday, October 26, 2016 2:23 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>; Kirk Hall
<Kirk.Hall at entrustdatacard.com>; Gervase Markham <gerv at mozilla.org>
Cc: Rob Stradling <rob.stradling at comodo.com>
Subject: Re: [cabfpub] Allowing SHA-1 OCSP and CRL signatures past 2016
Back on topic...
Please could somebody give me one good reason why CAs still need to sign
OCSP responses with SHA-1.
We switched to SHA-2 for signing all OCSP responses several months ago.
We've not received any customer complaints AFAIK.
Windows XP SP2 and earlier only supports SHA-1 for certs, but it doesn't
support OCSP at all without third-party add-ons.
On 26/10/16 22:20, Rob Stradling via Public wrote:
> On 26/10/16 16:40, Kirk Hall via Public wrote:
>> Helpful suggestion, Gerv - thanks.
>> On the question of whether our change of processes to comply with our IPR
Policy must be complete and immediate, I think about the prayer of the St.
Augustine who was trying to mend his ways: "Oh Lord, make me pure, but not
> Kirk, we're drifting way off-topic here, but...
>  suggests that Augustine wasn't really trying to mend his ways when
> he prayed that prayer.
> If we could somehow ask Augustine his opinion on this IPR compliance
> issue, I'd like to think (after reading ) that he'd quote something
> from Paul's Epistle to the Romans - perhaps the beginning of chapter 6:
> "Shall we go on sinning, so that grace may increase? By no means!"
>> After years of not following the exact procedures of our IPR Policy, we
have decided to pause new Guidelines changes that are not time critical in
order to get our existing Guidelines in order. That process will be
complete by about Jan. 7, and new Maintenance Guidelines can then be
approved by about Feb. 15. Unfortunately that is too late for Wayne's
amendment which needs to be approved by Dec. 31 to prevent CAs from being
out of compliance with current BR 7.1.3. It seems everyone agrees that
Wayne's amendment makes sense.
>> So how about this as an alternate plan?
>> 1. We pass Wayne's ballot now in the "old" fashion - 7 days discussion, 7
days vote. The change would then go into the "old" BRs so CAs can be
assured they will be in compliance after Dec. 31. I don't think there would
be any criticism by regulators, etc. in doing this so long as we continue to
move toward full compliance with our IPR Policy.
>> 2. This week we also modify Ballot 180 to include Wayne's amendment - we
treat this change as part of the 7 day discussion period that is currently
underway. In this way, the new language will be adopted in accordance with
our IPR Policy, and there will be no gaps.
>> -----Original Message-----
>> From: Gervase Markham [mailto:gerv at mozilla.org]
>> Sent: Wednesday, October 26, 2016 2:42 AM
>> To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; public at cabforum.org
>> Subject: Re: [cabfpub] Allowing SHA-1 OCSP and CRL signatures past
>> On 26/10/16 01:26, Kirk Hall via Public wrote:
>>> I think we can treat this as a Maintenance Guideline to Sec. 7.1.3
>>> of the BRs because we need to complete the adoption process by
>>> December 31.
>> As Ryan comments, I think this is unwise. May I propose the alternative
solution of each root program agreeing that this change is reasonable?
>> You already have the assent of Mozilla, Google and (implicitly)
>> We can then pass a ballot after the IPR situation is sorted out but have
it apply retrospectively.
>> Hopefully between those two things, we shouldn't have a significant
>> Public mailing list
>> Public at cabforum.org
Senior Research & Development Scientist
COMODO - Creating Trust Online
Public mailing list
Public at cabforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5725 bytes
Desc: not available
More information about the Public