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

From: William Conner <[email-masked]>
Date: Fri, 28 Apr 2017 11:40:57 -0500

I believe that this submission is relevant to this working group.  Feedback
welcome.

Thanks,
William

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Apr 14, 2017 at 9:51 AM
Subject: New Version Notification for draft-wconner-blake2sigs-00.txt
To: Adam Langley <[email-masked]>, William Conner <[email-masked]>,
Andrei Popov <[email-masked]>, Andrei Popov <
[email-masked]>, Ryan Sleevi <[email-masked]>

A new version of I-D, draft-wconner-blake2sigs-00.txt
has been successfully submitted by William Conner and posted to the
IETF repository.

Name:           draft-wconner-blake2sigs
Revision:       00
Title:          BLAKE2 Algorithms and Identifiers for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile
Document date:  2017-04-14
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-wconner-blake2sig
s-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/
Htmlized:       https://tools.ietf.org/html/draft-wconner-blake2sigs-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wconner-blake2s
igs-00

Abstract:
   This document describes the conventions for using the BLAKE2b-512
   hash function with each of the following signature algorithms: RSA
   Public-Key Cryptography Standards #1 version 1.5 (RSA PKCS#1 v1.5),
   RSA Probabilistic Signature Scheme (RSASSA-PSS), RSA Encryption
   Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP), Elliptic
   Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital
   Signature Algorithm (EdDSA).  This specification applies to the
   Internet X.509 Public Key Infrastructure (PKI) when digital
   signatures are used to sign certificates and certificate revocation
   lists (CRLs).  This document also specifies the object identifiers
   (OIDs) for the combinations of the BLAKE2b-512 hash function with the
   aforementioned signature algorithms.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Jim Schaad <[email-masked]>
Date: Fri, 28 Apr 2017 20:28:42 +0200

Just some really fast first impressions.

1.	What is the opinion of CFRG for Blake?   I note that the algorithm definition is published as an Independent stream document and I don’t remember getting any CFRG review at the time.
2.	Please don’t do PKCS v1.5 signatures.  We need to make these go away.
3.	This seems to have a lot of TBD work that is not marked as such.

Jim

From: Spasm [mailto:[email-masked]] On Behalf Of William Conner
Sent: Friday, April 28, 2017 6:41 PM
To: [email-masked]
Subject: [Spasm] Fwd: New Version Notification for draft-wconner-blake2sigs-00.txt

I believe that this submission is relevant to this working group.  Feedback welcome.

Thanks,

William

---------- Forwarded message ----------
From: <[email-masked] <mailto:[email-masked]> >
Date: Fri, Apr 14, 2017 at 9:51 AM
Subject: New Version Notification for draft-wconner-blake2sigs-00.txt
To: Adam Langley <[email-masked] <mailto:[email-masked]> >, William Conner <[email-masked] <mailto:[email-masked]> >, Andrei Popov <[email-masked] <mailto:[email-masked]> >, Andrei Popov <[email-masked] <mailto:[email-masked]> >, Ryan Sleevi <[email-masked] <mailto:[email-masked]> >

Name:           draft-wconner-blake2sigs
Revision:       00
Title:          BLAKE2 Algorithms and Identifiers for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Document date:  2017-04-14
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-wconner-blake2sigs-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/
Htmlized:       https://tools.ietf.org/html/draft-wconner-blake2sigs-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-00

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .

The IETF Secretariat

---

From: Russ Housley <[email-masked]>
Date: Sun, 30 Apr 2017 15:05:49 -0400

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 <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 think more needs to be said about the parameters field.  For example, RFC 4055 provides a syntax for parameters for RSASSA-PSS
and RSAES-OAEP.  I think that the intent here is that the object identifier implies a value for each of those parameters.  The text needs to be expanded to give the details.  Using RSAES-OAEP as an example, you need to say that the hashFunc is BLAKE2b-512, the maskGenFunc is MGF1 with BLAKE2b-512, and the pSourceFunc is pSpecifiedEmptyIdentifier (which in the nullOctetString).

Security considerations are needed.  At a minimum, you should point to the security considerations in RFC 5280 and https://blake2.net/blake2_20130129.pdf <https://blake2.net/blake2_20130129.pdf>.

Russ

> On Apr 28, 2017, at 12:40 PM, William Conner <[email-masked]> wrote:
> 
> From: <[email-masked] <mailto:[email-masked]>>
> To: Adam Langley <[email-masked] <mailto:[email-masked]>>, William Conner <[email-masked] <mailto:[email-masked]>>, Andrei Popov <[email-masked] <mailto:[email-masked]>>, Andrei Popov <[email-masked] <mailto:[email-masked]>>, Ryan Sleevi <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/internet-drafts/draft-wconner-blake2sigs-00.txt <https://www.ietf.org/internet-drafts/draft-wconner-blake2sigs-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/ <https://datatracker.ietf.org/doc/draft-wconner-blake2sigs/>
> Htmlized:       https://tools.ietf.org/html/draft-wconner-blake2sigs-00 <https://tools.ietf.org/html/draft-wconner-blake2sigs-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-00 <https://datatracker.ietf.org/doc/html/draft-wconner-blake2sigs-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Sun, 30 Apr 2017 15:13:54 -0400

Jim:

> Please don’t do PKCS v1.5 signatures.  We need to make these go away. 

I’d like to see the community move to better structures too, but I do not see that happening quickly.  TLS 1.3 discussed using RSA-PSS for signatures on the finished message, but it was felt that too many hardware security modules could not do that for quite some time.  The WG did not want RSA-PSS to be the thing that prevented wide deployment of TLS 1.3, so it continues to support PKCS#1 v1.5 signatures as well.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Sun, 30 Apr 2017 22:08:20 +0200

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.

Jim

From: Russ Housley [mailto:[email-masked]] 
Sent: Sunday, April 30, 2017 9:14 PM
To: Jim Schaad <[email-masked]>
Cc: William Conner <[email-masked]>; SPASM <[email-masked]>
Subject: Re: [Spasm] New Version Notification for draft-wconner-blake2sigs-00.txt

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 30 Apr 2017 19:22:41 -0400

On Sun, Apr 30, 2017 at 4:08 PM, 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.