Re: [lamps] Double signatures

Jim Schaad <ietf@augustcellars.com> Mon, 10 September 2018 19:42 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E5130F5C for <spasm@ietfa.amsl.com>; Mon, 10 Sep 2018 12:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ENtOLWfoYDwt for <spasm@ietfa.amsl.com>; Mon, 10 Sep 2018 12:42:18 -0700 (PDT)
Received: from mail2.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 C8649130F59 for <spasm@ietf.org>; Mon, 10 Sep 2018 12:42:17 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 10 Sep 2018 12:38:13 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>
CC: 'SPASM' <spasm@ietf.org>, <x500standard@freelists.org>, <era@x500.eu>
References: <005a01d44916$7c9cb560$75d62020$@x500.eu> <CAErg=HHhU9H-Ng8sUtXu2S+F0fr2tLOX6=8UR77gz0YLqtGyaA@mail.gmail.com> <004a01d44928$b1500d40$13f027c0$@augustcellars.com> <a94fb26ed9aa46738bea040919bf96b7@XCH-ALN-010.cisco.com>
In-Reply-To: <a94fb26ed9aa46738bea040919bf96b7@XCH-ALN-010.cisco.com>
Date: Mon, 10 Sep 2018 12:42:07 -0700
Message-ID: <006501d4493e$5dc09850$1941c8f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01D44903.B163BC20"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEeKhTkIyWJvDJmtkckrYoYnqsyLAKU/EXwAvtpPxkB+phnTaYZzkSQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/BU0SKSggz1Fa0gYBrTBovjcJ5NQ>
Subject: Re: [lamps] Double signatures
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2018 19:42:21 -0000

First – they say that this is not going to done in certificates which means that all of the questions dealing with certificates  have gone out the window.

 

Second – the issue around semantics of multiple parallel signatures is always dependent on the application being used.   This is how things are defined for CMS which has the same issue (RFC 5752).  Since this is not for certificates, that is not immediately a problem for the IETF.  If one did the define a signature algorithm, one could even encode much of these semantic rules into the algorithm definition either directly in the OID or as parameters.

 

Third – processing issues for this are quite simple.  The version that was presented in LAMPs had a lot of problems in doing the order of signing and building the resulting item as there needed to be at least two different passes of encoding which needed to do the same things.  That is not an issue here as the exact same bytes are signed by all of the signature algorithms in question.

 

Jim

 

 

From: Panos Kampanakis (pkampana) <pkampana@cisco.com> 
Sent: Monday, September 10, 2018 12:01 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'SPASM' <spasm@ietf.org>rg>; x500standard@freelists.org; era@x500.eu
Subject: RE: [lamps] Double signatures

 

Hi Jim, 

I think the issues brought up about draft-truskovsky-lamps-pq-hybrid-x509 are pretty similar even if the altSig information is added in the signed data type if that sig coexists with the traditional sig. Can you elaborate why are you saying otherwise?

Panos

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' <ryan-ietf@sleevi.com <mailto:ryan-ietf@sleevi.com> >; era@x500.eu <mailto:era@x500.eu> 
Cc: 'SPASM' <spasm@ietf.org <mailto:spasm@ietf.org> >; x500standard@freelists.org <mailto:x500standard@freelists.org> 
Subject: Re: [lamps] Double signatures

 

Ryan,

 

The discussion in London dealt with a completely different proposal than this one.  While I think there are problems with this that need to be dealt with they are mostly not the same set.

 

Erik,

 

Why is this considered to be a preferred solution to defining a new signature algorithm which contains as the parameter the sequence of algorithm identifiers and as the signature value a sequence of signature values.  The problem with just defining the extension to SIGNED is that one needs to make sure that the set of signature algorithms and parameters are also part of the data to be signed and I am not seeing that highlighted here.

 

Jim

 

 

From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org> > On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To: era@x500.eu <mailto:era@x500.eu> 
Cc: SPASM <spasm@ietf.org <mailto:spasm@ietf.org> >; x500standard@freelists.org <mailto:x500standard@freelists.org> 
Subject: Re: [lamps] Double signatures

 

 

On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <era@x500.eu <mailto:era@x500.eu> > wrote:

Hi Folk,

 

In ITU-T we have plans to allow for double signatures using the SIGNED parametrized data type defined in X.509 to cope with situation as described in the internet draft: “Multiple Public-Key Algorithm X.509 Certificates (draft-truskovsky-lamps-pq-hybrid-x509-01)”

 

We suggest to enhance the SIGNED data type as shown below:

 

SIGNED{ToBeSigned} ::= SEQUENCE {

  COMPONENTS OF SIGNATURE,

  ....,

  altAlgorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,

  altSignature            BIT STRING OPTIONAL  

  } (WITH COMPONENTS {..., altAlgorithmIdentifier PRESENT, altSignature PRESENT } |

     WITH COMPONENTS {..., altAlgorithmIdentifier ABSENT,  altSignature ABSENT } )

 

We are open to comments. We know that IETF is not a heavy user of this data type.

 

We have no intention to use this extended data type for certificates and CRLs.

 

For your information, SIGNATURE is defined as:

 

SIGNATURE ::= SEQUENCE {

  algorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}},

  signature            BIT STRING,

  .... }

 

>From the discussions in London (101), there were a number of challenges identified during the discussion - https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt - that fundamentally questioned that approach.

 

Has the ITU-T addressed or resolved those concerns? Are they not applicable for some reason specific to ITU-T?