Re: [lamps] Double signatures

Sean Turner <sean@sn3rd.com> Wed, 12 September 2018 02:04 UTC

Return-Path: <sean@sn3rd.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 67BD9130E14 for <spasm@ietfa.amsl.com>; Tue, 11 Sep 2018 19:04:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 wG_cFGRHm3i4 for <spasm@ietfa.amsl.com>; Tue, 11 Sep 2018 19:04:28 -0700 (PDT)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C12130E0A for <spasm@ietf.org>; Tue, 11 Sep 2018 19:04:27 -0700 (PDT)
Received: by mail-qt0-x241.google.com with SMTP id r37-v6so367603qtc.0 for <spasm@ietf.org>; Tue, 11 Sep 2018 19:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xgMAO81zYalBcwmvw2XkedNWh2adTxNrmGNhDPg+kpE=; b=KAsjZHk8XgKu50hNmsIyTJ5REK1o6OvtaFwBO9CB4OqqeBIprB51jsXTtX0F6k5v92 peqO1BmtldI0/hPhvc3uFuZ4dcVCjSUN/p5PwhLov50+h9m1tR/F7psBcn4hZ5AsIf0k 33IJ8OaeSOzrQmHmgeQIii9izBXd09HLvf1+Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xgMAO81zYalBcwmvw2XkedNWh2adTxNrmGNhDPg+kpE=; b=sI9OnRmF8c1+938fKVm87Oq4YfOYIPJODey0BISDRpRYTMQku9+BHgvKB8mfFzwyLn k659WN7AJcu75TFWusH3m4E9ZUlFruckuJU6rM3o+dCVq379gyWhLZSqf0CrTvcwcx/Q 68U5zH5QuACYrcUlVgno210NKCDH+gVLB+Y7ACMe7Ug5HR6Ju5RpnsXeqhJpFVURIlZY +o/7p0H3rSAajWagSoCbWFzdjzAuKP4sOwJhe7bLLlwnp08+YKQoKcZfiLADAGjylHOU pXNak/X2Em/FwWOZyNaRlTSRv0adaYUeslJVGBpIWGgLyvKv1FVhtPQlPi2edrwG7der AvEA==
X-Gm-Message-State: APzg51Ckvu5kfxRm5B7/uIswP1TombE8cE/ToMAlsNoOfyT+HI6Amjwd otoqnuk/ayxdrqR1803VN4uftxiQ5Gk=
X-Google-Smtp-Source: ANB0VdaRb14sijOc45xhAFyyJurEQknXzXUOsUvU3KGKHFbaKlTKtAcGEWkIZ4petXnFWVNM6kiJlA==
X-Received: by 2002:ac8:2a13:: with SMTP id k19-v6mr21563687qtk.245.1536717866951; Tue, 11 Sep 2018 19:04:26 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.216.107]) by smtp.gmail.com with ESMTPSA id f129-v6sm10883270qkb.40.2018.09.11.19.04.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 19:04:25 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <003101d4499d$388e9af0$a9abd0d0$@x500.eu>
Date: Tue, 11 Sep 2018 22:04:23 -0400
Cc: SPASM <spasm@ietf.org>, x500standard@freelists.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FDF830E2-F1FD-411D-B98E-1C1CC0A8E341@sn3rd.com>
References: <005a01d44916$7c9cb560$75d62020$@x500.eu> <CAErg=HHhU9H-Ng8sUtXu2S+F0fr2tLOX6=8UR77gz0YLqtGyaA@mail.gmail.com> <004a01d44928$b1500d40$13f027c0$@augustcellars.com> <003101d4499d$388e9af0$a9abd0d0$@x500.eu>
To: Erik Andersen <era@x500.eu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/mRs2P-5BTTp-TdGz43oL8GnznxI>
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: Wed, 12 Sep 2018 02:04:30 -0000

Erik,

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.

spt

> On Sep 11, 2018, at 03:01, Erik Andersen <era@x500.eu> 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 [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> On Behalf Of Ryan Sleevi
> Sent: Monday, September 10, 2018 8:53 AM
> To: era@x500.eu
> Cc: SPASM <spasm@ietf.org>rg>; x500standard@freelists.org
> Subject: Re: [lamps] Double signatures
>  
>  
> 
> On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen <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? 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm