Re: [lamps] Double signatures

"Erik Andersen" <> Fri, 14 September 2018 12:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEEA9130E36 for <>; Fri, 14 Sep 2018 05:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id azo6jFEPDLrE for <>; Fri, 14 Sep 2018 05:20:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3978130E35 for <>; Fri, 14 Sep 2018 05:20:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60B9FCE698 for <>; Fri, 14 Sep 2018 14:20:25 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3XeWvW_Vc4ah for <>; Fri, 14 Sep 2018 14:20:24 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 75B1FCF146 for <>; Fri, 14 Sep 2018 14:20:24 +0200 (CEST)
Received: from Morten ([]) by (DanDomain Mailserver) with ASMTP id 2201809141420226551; Fri, 14 Sep 2018 14:20:22 +0200
From: "Erik Andersen" <>
To: "'SPASM'" <>, <>
Cc: "'SPASM'" <>, <>
References: <005a01d44916$7c9cb560$75d62020$> <> <004a01d44928$b1500d40$13f027c0$> <003101d4499d$388e9af0$a9abd0d0$> <>
In-Reply-To: <>
Date: Fri, 14 Sep 2018 14:20:20 +0200
Message-ID: <000601d44c25$4e31bb50$ea9531f0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-gb
Thread-Index: AQEeKhTkIyWJvDJmtkckrYoYnqsyLAKU/EXwAvtpPxkBVFrfMwIDk0E+phSybjA=
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: Fri, 14 Sep 2018 12:20:33 -0000

Hi Sean,

What I meant was that the optional addition to the SIGNED data type shall be absent for the two cases. However, I am slowly coming to the opinion that we should define a new data type and leave the SIGNED data type as it is to avoid confusion.

Best regards,


-----Oprindelig meddelelse-----
Fra: Spasm [] På vegne af Sean Turner
Sendt: 12 September 2018 04:04
Til: Erik Andersen <>
Cc: SPASM <>rg>;
Emne: Re: [lamps] Double signatures


A couple of points I’m hoping you might clarify:

1. You said “We have no intention to use this extended data type for certificates and CRLs.”  In X.509-2016, Certificate and CertificateList use the following ASN.1:
	Certificate ::= SIGNED{TBSCertificate}
	CertificateList ::= SIGNED{CertificateListContent}

So to pull off what you’re suggesting (i.e., never using these with Certificate and CertificateList) what exactly are going to do - redefine Certificate and CertificateList, put some kind of constraint on ToBeSigned in SIGNED, … ?

2. You also said "We know that IETF is not a heavy user of this data type”, where this is SIGNED.  That’s a true statement because the IETF initially didn’t make use of the AuthenticationFramework SIGNED parameterized types because RFC 5280 uses the ’88 modules and parameterized types were’t a thing in ’88; in ’88 it was a SIGNED MACRO and it was a pain so it was redefined in a bits-on-the-wire compatible way.  For those IETF RFCs that prefer to use the ’02 and ’08 syntax, a SIGNED parameterized type is defined in RFC 5912 and is used in RFCs 5911, 5912, and 6268 (and maybe others) to define 30+ ASN.1 modules.  So while "SIGNED” is not used much in the context of the 8000+ RFCs it can be used by just about every RFC that uses ASN.1.

Despite the fact SIGNED wasn’t defined exactly the same, they still resulted in the same encoding, namely algorithm parameters (OID+parameters) and signature (a bit string); same as the earlier ’88 syntaxes.  I have this sinking feeling that making a change to this is going to cause some problems somewhere despite the fact we can do fancy things with the ASN.1.


> On Sep 11, 2018, at 03:01, Erik Andersen <> wrote:
> 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 [] 
> Sendt: 10 September 2018 19:07
> Til: 'Ryan Sleevi' <>om>;
> Cc: 'SPASM' <>rg>;
> 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 <> On Behalf Of Ryan Sleevi
> Sent: Monday, September 10, 2018 8:53 AM
> To:
> Cc: SPASM <>rg>;
> 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:
>> SIGNED{ToBeSigned} ::= SEQUENCE {
>>   ...,
>>   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? 
> _______________________________________________
> Spasm mailing list

Spasm mailing list