Re: [lamps] Double signatures

"Erik Andersen" <era@x500.eu> Tue, 11 September 2018 07:01 UTC

Return-Path: <era@x500.eu>
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 745FC130E39 for <spasm@ietfa.amsl.com>; Tue, 11 Sep 2018 00:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 ZsimIWmuirKz for <spasm@ietfa.amsl.com>; Tue, 11 Sep 2018 00:01:18 -0700 (PDT)
Received: from smtpscan3.dandomain.dk (smtpscan3.dandomain.dk [194.150.112.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B33E1277CC for <spasm@ietf.org>; Tue, 11 Sep 2018 00:01:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id 1C8D3932E7 for <spasm@ietf.org>; Tue, 11 Sep 2018 09:01:16 +0200 (CEST)
Received: from smtpscan3.dandomain.dk ([127.0.0.1]) by localhost (smtpscan3.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdyKnS42P4t2 for <spasm@ietf.org>; Tue, 11 Sep 2018 09:01:14 +0200 (CEST)
Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id 3F875B8BD0 for <spasm@ietf.org>; Tue, 11 Sep 2018 09:01:14 +0200 (CEST)
Received: from Morten ([62.44.134.2]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201809110901111953; Tue, 11 Sep 2018 09:01:11 +0200
From: "Erik Andersen" <era@x500.eu>
To: "'SPASM'" <spasm@ietf.org>, <x500standard@freelists.org>
References: <005a01d44916$7c9cb560$75d62020$@x500.eu> <CAErg=HHhU9H-Ng8sUtXu2S+F0fr2tLOX6=8UR77gz0YLqtGyaA@mail.gmail.com> <004a01d44928$b1500d40$13f027c0$@augustcellars.com>
In-Reply-To: <004a01d44928$b1500d40$13f027c0$@augustcellars.com>
Date: Tue, 11 Sep 2018 09:01:10 +0200
Message-ID: <003101d4499d$388e9af0$a9abd0d0$@x500.eu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01D449AD.FC176AF0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQEeKhTkIyWJvDJmtkckrYoYnqsyLAKU/EXwAvtpPxmmKmJB4A==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/p2gSbboJOobz_Mm1mL3njGKBv3E>
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: Tue, 11 Sep 2018 07:01:21 -0000

HI Jim,

 

You have a good point here that also been bothering me for the last couple of days. I am still trying to find a way.

 

Erik

 

Fra: Jim Schaad [mailto:ietf@augustcellars.com] 
Sendt: 10 September 2018 19:07
Til: 'Ryan Sleevi' <ryan-ietf@sleevi.com>om>; era@x500.eu
Cc: 'SPASM' <spasm@ietf.org>rg>; x500standard@freelists.org
Emne: 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?