[cabfpub] SHA-1 Collision Found

[Ryan Sleevi]

On Thu, Feb 23, 2017 at 7:54 PM, Phillip Hallam-Baker <philliph at comodo.com>
wrote:

> I did try to get SHA-3 added to the CURDLE working group work items. And I
> was told that nobody was asking for it.
>

I see. Did you mention that in the Forum in the past? Did you try to build
effort and consensus on next steps?

Put differently, what you've provided in this email is mostly complaints.
I'm trying to find out if you're suggesting solutions in these complaints,
and I'm just misunderstanding them, or if you're just complaining. If you
are just complaining, I'm hoping to push you to make concrete suggestions
about how the Forum, as an industry, can take productive steps. The extent
of discussion you've provided in the Forum, versus the tone of the emails
and nature of complaints, does not seem to align, so I'm trying to
understand where the misunderstanding is.


> Things have to break before some people will act. Which is why I consider
> the proposal to further reduce validity intervals to provide more
> procrastination time positively harmful. The SHA-2 transition took a
> decade. We could have started five years earlier.
>

I see. So in Comodo's view, you are opposed to reducing certificate
lifetimes because you believe that, rather than helping enact change
sooner, it postpones change? That's an interesting perspective, but I don't
think it's supported by the data or any past action by the Forum. I would
also suggest that you might be more productive and persuasive if you
decouple those things, and instead focus on the solutions you'd like to
see, and how to go towards that.


> SHA-2 is a direct swap for SHA-3 however. All that is required is to
> define the necessary OIDs. And the CURDLE charter does not preclude SHA-3,
> it merely does not list them as current work items.
>

If you believe it's "just OIDs", then why hasn't Comodo made any proposals,
given http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html
? Were you simply unaware of the OID assignment? Or is your assertion that
such an OID as "id-rsassa-pkcs1-v1_5-with-sha3-256" ( { sigAlgs 13 } ) is
insufficient?

I'm not sure how to interpret the rest of your reply, so I've omitted it,
but I'm still curious about whether there are "any HSM vendors that CAs
might use to ensure that their private keys are appropriately protected
when generating these signatures?"

Doesn't this seem key to understanding how such certificates might exist,
with respect to key protection, which is necessary and critical for user
agents and cryptographic libraries to feel confident that supporting such
certificates does not introduce undue risk to their users?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170223/a9d1445f/attachment-0003.html>