Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt

Jim Schaad <ietf@augustcellars.com> Mon, 08 May 2017 21:17 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0941201F8 for <curdle@ietfa.amsl.com>; Mon, 8 May 2017 14:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHfnfUmlvItR for <curdle@ietfa.amsl.com>; Mon, 8 May 2017 14:17:50 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145FE1293E3 for <curdle@ietf.org>; Mon, 8 May 2017 14:17:50 -0700 (PDT)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1494278266; h=from:subject:to:date:message-id; bh=sbJaaffshDlJGCoRbCZGAX3uUyhiAZgT4KcQbumnBC4=; b=MFVvUmTTz+p0Qiwvwus8YXO8K5mWtuD//cjKcpO9PozGDarGzvljWCHBSlAv58KcqBvLmfLUiJH IQXPrj4GQXlXkIa9nm0HziQzmlnFTBaXk9m1oRyYTTL4OQ2mM6aumiEGzE3Q70jCPVWbNnFpN93/J tTH3+Cy0lZdd8Ht62kSaWtMqZ2G5js7BEeg+dk3fO9mMW/KWpMe4Uh1nqpu/fxCKrKikTMIL5ykgY 511X/xxw0qyXzS304ZELRJg7vQOru4CQoqU1nyjIKDStMQK/mnWiUOcDKGJsZQuvWLtoFOcFS8yJ8 BFZekmzMwCkPYoJ4oJlIwrmrv0DQz9P/137w==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 14:17:46 -0700
Received: from Hebrews (24.20.67.136) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 8 May 2017 14:17:34 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>, 'curdle' <curdle@ietf.org>
CC: 'Eric Rescorla' <ekr@rtfm.com>
References: <CABcZeBMRYwdQnxUuBrCEsM-BeTFfARg3ZFn=tWh+5FMdv2WGYw@mail.gmail.com> <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com>
In-Reply-To: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com>
Date: Mon, 08 May 2017 14:17:54 -0700
Message-ID: <009d01d2c840$906fbdb0$b14f3910$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQDzjLssHQiGh7cNRgcgGtsfeGOhcALbPNLgo5KMffA=
X-Originating-IP: [24.20.67.136]
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/x5dE8n6HXOBKK2LDJtAq-Hc9iSg>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 May 2017 21:17:52 -0000


-----Original Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Monday, May 8, 2017 10:32 AM
To: curdle <curdle@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt


> TECHNICAL
> S 3.1 and 3.2.
> - Is there some reason to not prescribe exactly one form here?
>   I.e., require id-sha512 (etc.) or require it not be there?
> 
> - Also, TLS has converged on talking about an "identity" hash
>   for the PureEd forms. Was this discussed and rejected?

CMS supports signatures with and without signed attributes.  In most cases, signed attributes are present.  When signed attributes are present, the message-digest attribute MUST be one of the attributes.  Eric is suggesting that the “identity” hash could be used with Ed25519 and Ed448 when there are no attributes to hash.  Using ED25519 as an example, we get:

   IF (signed attributes are absent)
   THEN
	signedData.digestAlgorithms includes id-hashIdentity
        signedData.signerInfo.digestAlgorithm = id-hashIdentity
        signedData.signerInfo.signature = Ed25519(content)
   ELSE
	signedData.digestAlgorithms includes id-sha512
        signedData.signerInfo.digestAlgorithm = id-sha512
	signedData.signerInfo.signedAttrs includes message-digest = SHA512(content)
        signedData.signerInfo.signature = Ed25519(DER(signedData.signerInfo.signedAttrs))

Do others think the use of an algorithm identifier for the “identity” hash is better?  The current document include id-sha512 as a warning that Ed25519 uses that hash algorithm internally.

[JLS]  Creation of an identity hash function would certainly be a good way to give the hint that the entirety of the content is going to be needed or the signature algorithm.  As such it sounds like a good idea.  My worry would be about potential misuse of this as a hash function in other contexts.  For example, what happens if you used the identity hash unction when signed attributes are present?  Does this mean that you end up with two copies of the content in the resulting SignedMessage object?  Where would it get abused that might be problematic. 

On the balance however, I think this is a better idea than not having the indicator.  It is just going to need some caveats around it.  I still think I just prefer saying that you must have the attributes present, but that ship is probably never going to sail.

Jim


Russ
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle