Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt

From: Brian Smith <[email-masked]>
Date: Mon, 1 May 2017 09:31:51 -1000

Russ Housley <[email-masked]> wrote:
> As a matter of taste, I’d prefer to see the Object Identifiers assigned in
> the PKIX algorithm arc:
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6
>
> The Object Identifiers will be slightly smaller, but not enough to argue
> about.  My preference is to have them assigned in an arc that is managed by
> IANA.

I disagree with this. OIDs should be as small as possible to maximize
the number of (constrained) situations the standard can be used.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Mon, 1 May 2017 09:39:24 -1000

Ryan Sleevi <[email-masked]> wrote:
> > Jim Schaad <[email-masked]> wrote:
>>
>> I think that that is a regrettable but understandable opinion for an
>> existing signature algorithm.  I find it less convincing for a new signature
>> algorithm.
>
> Why is that?
>
> Many HSMs can handle this as well - using CKM_RSA_PKCS, in which the caller
> provides the encoded digest algorithm OID and hash, and the HSM performs the
> overall encapsulation. This was very much at the forefront of CAs concerns.
> It also simplifies implementations with many existing cryptographic
> libraries.

According to the draft itself, the motivation for the draft is to have
a backup in case of a failure of a cryptographic algorithm,
specifically one or more of the SHA-2 algorithms. It seems likely that
the PKCS#1 signature scheme will fail before any of the SHA-2
algorithms fail.

Accordingly, I agree with Jim. Extending PKCS#1 with any new digest
algorithms is a bad idea. Let's get rid of PKCS#1. Instead, it would
be better to specify a deterministic full-domain-hash signature scheme
instead of PKCS#1, alongside RSA-PSS.

FWIW, some PKCS#11 modules also implement the RAW RSA mechanisms,
which allow RSA-PSS and other (in particular, deterministic
full-domain hash) algorithms to be implemented. There's really not
much advantage to a HSM implementing CKM_RSA_PKCS for arbitrary digest
algorithms, but not implementing the RAW RSA primitive.

Note also that some modules may implement CKM_RSA_PKCS, but whitelist
the digest algorithms that are supported for use with it.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 May 2017 09:53:46 +0200

From: Ryan Sleevi [mailto:[email-masked]] 
Sent: Monday, May 1, 2017 1:23 AM
To: Jim Schaad <[email-masked]>
Cc: Russ Housley <[email-masked]>; SPASM <[email-masked]>; William Conner <[email-masked]>
Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt

On Sun, Apr 30, 2017 at 4:08 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

I think that that is a regrettable but understandable opinion for an existing signature algorithm.  I find it less convincing for a new signature algorithm.

Why is that?

Many HSMs can handle this as well - using CKM_RSA_PKCS, in which the caller provides the encoded digest algorithm OID and hash, and the HSM performs the overall encapsulation. This was very much at the forefront of CAs concerns. It also simplifies implementations with many existing cryptographic libraries.

[JLS] The fact that one can create such a signature is not all of the relevant to my argument.  However, I don’t see that documented as a normal PKCS#11 interface.  Like Brian, I have a vague memory of being able to sign an arbitrary value, but I don’t see it off hand in the PKCS#11 spec either so I don’t know why I thought that to be true.

My argument is that this is a new signature algorithm.  I am trying to kill PKCS v1.5 signature.  Therefore I see no need to create a new PKCS v1.5 signature with a new hash algorithm.  The fact that it can be implemented does not have anything to do with this.  The fact that Ilari has presented a weak argument for collisions between PKCS v1.5 and PSS also pushes me to want to just have PSS.

Jim

---

From: Rob Stradling <[email-masked]>
Date: Tue, 2 May 2017 11:16:25 +0100

> the number of (constrained) situations the standard can be used.

+1

draft-ietf-curdle-pkix and draft-ietf-trans-rfc6962-bis both use OIDs 
that were generously donated by Symantec/thawte from their (short) 
1.3.101 arc.

I suggest inviting Symantec to donate some 1.3.101.<x> OIDs for 
draft-wconner-blake2sigs too.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 May 2017 12:47:35 +0000

> I suggest inviting Symantec to donate some 1.3.101.<x> OIDs for draft-
> wconner-blake2sigs too.

Work is in progress to turn the arc over to IETF / IANA / someone-like-us.