Re: [lamps] Double signatures

"Santosh Chokhani" <> Mon, 10 September 2018 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C68D130EEC for <>; Mon, 10 Sep 2018 10:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zTfz-53ixBHd for <>; Mon, 10 Sep 2018 10:18:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5CB4130EE1 for <>; Mon, 10 Sep 2018 10:18:00 -0700 (PDT)
Received: by with SMTP id n6-v6so25036585qtl.4 for <>; Mon, 10 Sep 2018 10:18:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=bOr3JI8xoE57C2W3T5nrQkDgfRzsaOKBvVSPRHyc38g=; b=AVYbLqlTo0ekq4vBUP5iDoLBt0TPmlYR7WznXJILcCRZ/NeYaBihdF+YUYCbxr7/8D zAIFzz85Eql1iNMX9oasxjcYhNRfb1DSEGsKQORj3LjvmO9REAAv/KvXG9lCX3ISdSwc hcJk2muoSps9fCiLj1Il4ImuKE/GR9CBH10V2eIDayt5eha/6qGHesvQcyLMxLAV4+dG z2nFz0mhMjNQ/XDeWhW2ZxSBnz4y2ABa1US/nv7iylrCbFZ5b+LdkQGtq/YjKMcQG6jo pq6JtNBq93en3FwHiaf0xV6QRnRY5mRxDNhDqEjjPr7wABD/dnVbdBUDwdXwO/Lsi9ev 5Q9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=bOr3JI8xoE57C2W3T5nrQkDgfRzsaOKBvVSPRHyc38g=; b=pAnH0h0iDMvYeSuf92ARsFsDdJ5Oc12ktGTKgwtORaLIYdNqRpXJ+I14NRtdH/lhna iF5LS0CeZMSeLu9BB6DnB5jIPiqywzXFfOGpIKWzCvpvj4aXrw663uLYio/eEm3M7XeZ yD3r0LY/oYczToz6oWmafTRLNYOl1cZIlJW7kpC75EKb0HrNqSN4aujL/V5QKQS1KlS9 G0RS9T6K5qglw1wlqbAg6puRynlbRuUMhaASqEa2ewkjY1Y/7ZZGyarQirkE1bdaLIJM HqtE8fy4DECOWilmdGtMCyRVh7CszmAd97a0uulOryWjOjw7nrbIuUjS82+KEQzJijGP +a5Q==
X-Gm-Message-State: APzg51DgYsffsGUxURIGQhZtsDq0Yf86BWHZjOnWZq+PjzNSA2plrvp4 BlzSwFxUeb3XcWB0SDwod3QJFM8a
X-Google-Smtp-Source: ANB0Vdb9mU9zRfDzClImAhTzbwK680/t4H/jOMNaFFcWXeN3GHWqZ4kqnFBGBxOwGgOoq3FjYMXyfg==
X-Received: by 2002:ac8:3ac1:: with SMTP id x59-v6mr17054032qte.8.1536599880098; Mon, 10 Sep 2018 10:18:00 -0700 (PDT)
Received: from SantoshBrain ( []) by with ESMTPSA id j129-v6sm10111454qke.56.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 10:17:59 -0700 (PDT)
From: "Santosh Chokhani" <>
To: "'Jim Schaad'" <>, "'Ryan Sleevi'" <>, <>
Cc: "'SPASM'" <>, <>
References: <005a01d44916$7c9cb560$75d62020$> <> <004a01d44928$b1500d40$13f027c0$>
In-Reply-To: <004a01d44928$b1500d40$13f027c0$>
Date: Mon, 10 Sep 2018 13:17:59 -0400
Message-ID: <04ce01d4492a$39400ce0$abc026a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04CF_01D44908.B230B6D0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQEeKhTkIyWJvDJmtkckrYoYnqsyLAKU/EXwAvtpPxmmKXti4A==
Content-Language: en-us
Archived-At: <>
Subject: Re: [lamps] Double signatures
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Sep 2018 17:18:03 -0000

Why not let algorithm identifier dictate the number of signatures and their syntax?


From: Spasm [] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' <>om>;
Cc: 'SPASM' <>rg>;
Subject: Re: [lamps] Double signatures




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.




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.





From: Spasm < <> > On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To: <> 
Cc: SPASM < <> >; <> 
Subject: Re: [lamps] Double signatures



On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen < <> > 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:





  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:



  algorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}},

  signature            BIT STRING,

  .... }


>From the discussions in London (101), there were a number of challenges identified during the discussion - - 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?