Re: [lamps] Double signatures
"Santosh Chokhani" <santosh.chokhani@gmail.com> Wed, 12 September 2018 21:47 UTC
Return-Path: <santosh.chokhani@gmail.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 ABC45130D7A for <spasm@ietfa.amsl.com>; Wed, 12 Sep 2018 14:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T4r70v-eQms0 for <spasm@ietfa.amsl.com>; Wed, 12 Sep 2018 14:47:30 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 A6FEE126F72 for <spasm@ietf.org>; Wed, 12 Sep 2018 14:47:29 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id z125-v6so2069100qkb.12 for <spasm@ietf.org>; Wed, 12 Sep 2018 14:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=adeTu7iQyJIs3f8IhFTTv7TTYVbWzcfzKpFpdF3+Gts=; b=m0pl23JbS6qRxdPyPGTaoGIvEczkyqgKhz3KikT4NKha8afKKI9L9uIlPl1+oLMq7V 2H2fHk6zSwJgIvogBJ3mKyj7PUa1og0Otwz0FmNLOon0m0moTuSg6F9ppJ85EVm8hjD7 sLh6hFaHCqSn9I6jRJH1APyj4Buck+APzJe0jbEsA4raYrWnjSYDajzhPw/X8DiHpIwo aZp/fxGo3Ycv4kRnn7/pD12pP4jgWi88aEcXCWPqWmIucqT2sHUwCQKMP4tJbNgD5LQg qpFroOxrVX7VBAjgdjqdkmx1KUEQqktvTswM2GhtE1EtKJpbNxiGTwk/bavyzQIqFsrl 9TYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=adeTu7iQyJIs3f8IhFTTv7TTYVbWzcfzKpFpdF3+Gts=; b=dZKAVm7DnyiWv7MrSYQ5Lhrgeoq+bgttVcNTlVtIJKDcA8/VEbMAE2y4fGtxhdaLhZ sPB5jPFHmxwt0urs8U+pAFY8OvJuRlMI/chYhzp76pkEGHq8mdC4rLJ/2hi6gPZSTiKD jqDR5CtVrccsV5P7GZZ7MdBdUs48KISb/f1WEA0PmuTtjQT22NIbsX7G+xhwhMl6kJ0c OIEYEGZyRRrWqwdjRFn2W9PTXCh5wLxeosAXcik/yWbGsk9/zI8AWawI0mCCTIg2sswM Wutn1dOpLimnGiV2WLBJoS16D1ZXxhMqBCA4LKccuWRIBC0lvY14mJWtbcJN/m2zYjh7 HPzg==
X-Gm-Message-State: APzg51Bf0CC0inbEA0EVZlB2tc4Xtk0akJQJ8FhOVOeCI9I4S4bq2F9U XYyPOfLVFp5n34bYPsldMaygsqVh
X-Google-Smtp-Source: ANB0VdYpRGFjeWmzco7IuqXjgnYBmRyq9L3yL1cLfdpMSV/jHrzhFKbsdXs99a7JafxW1bsO8qjc8A==
X-Received: by 2002:a37:71c7:: with SMTP id m190-v6mr3058037qkc.275.1536788848713; Wed, 12 Sep 2018 14:47:28 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-191-57.washdc.fios.verizon.net. [173.73.191.57]) by smtp.gmail.com with ESMTPSA id 45-v6sm1366618qtt.89.2018.09.12.14.47.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 14:47:27 -0700 (PDT)
From: Santosh Chokhani <santosh.chokhani@gmail.com>
To: 'Jim Schaad' <ietf@augustcellars.com>, 'Russ Housley' <housley@vigilsec.com>, 'Massimiliano Pala' <M.Pala@cablelabs.com>
Cc: 'SPASM' <spasm@ietf.org>, 'Erik Andersen' <era@x500.eu>
References: <005a01d44916$7c9cb560$75d62020$@x500.eu> <CAErg=HHhU9H-Ng8sUtXu2S+F0fr2tLOX6=8UR77gz0YLqtGyaA@mail.gmail.com> <004a01d44928$b1500d40$13f027c0$@augustcellars.com> <04ce01d4492a$39400ce0$abc026a0$@gmail.com> <003601d4499e$7c8be3b0$75a3ab10$@x500.eu> <BN6PR14MB110623B94ED97509FAE9F71283040@BN6PR14MB1106.namprd14.prod.outlook.com> <087c01d449db$c78e6350$56ab29f0$@gmail.com> <BN6PR14MB1106DBDE49673AED8E6C937383040@BN6PR14MB1106.namprd14.prod.outlook.com> <9A1A8BFC-9670-42EA-8D8D-B3DC2494CB95@cablelabs.com> <798ACAFB-7417-42F5-BF1C-6C0765606AC0@vigilsec.com> <018c01d44aa9$39b79cd0$ad26d670$@augustcellars.com>
In-Reply-To: <018c01d44aa9$39b79cd0$ad26d670$@augustcellars.com>
Date: Wed, 12 Sep 2018 17:47:26 -0400
Message-ID: <000001d44ae2$328c5930$97a50b90$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D44AC0.AB81E520"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQEeKhTkIyWJvDJmtkckrYoYnqsyLAKU/EXwAvtpPxkCYiDthAIpj1iIAzshKQwBinJdFQHyxjh8AhUcZ2UCVBhheAFr+tbqpaQfvYA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/sNDV-QnejrESYbsgvPw4e00l7tE>
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 21:47:33 -0000
You can also add a bit map in the composite alg OID parameters field for which ones must be verified. From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, September 12, 2018 11:00 AM To: 'Russ Housley' <housley@vigilsec.com>; 'Massimiliano Pala' <M.Pala@cablelabs.com> Cc: 'SPASM' <spasm@ietf.org>; 'Erik Andersen' <era@x500.eu> Subject: Re: [lamps] Double signatures Russ, There are two easy ways to indicate this. The first would be to allocate multiple oids oid-One-Is-Ok-Multi-Sig oid-All-Required-Multi-Sig The second would be to put a int value before the sequence of signature oids with the number of signatures that needed to validate so you could do 3 of n need to validate. Jim From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org> > On Behalf Of Russ Housley Sent: Wednesday, September 12, 2018 5:13 AM To: Massimiliano Pala <M.Pala@cablelabs.com <mailto:M.Pala@cablelabs.com> > Cc: SPASM <spasm@ietf.org <mailto:spasm@ietf.org> >; Erik Andersen <era@x500.eu <mailto:era@x500.eu> > Subject: Re: [lamps] Double signatures Max: During a transition to quantum-resistant signatures, a signer wants to put a traditional signature and a quantum-resistant signature on an object. Given your description of keyUsage and extendedKeyUsage, both would have the digitalSignature bit set. How does a client know if just one or both signatures must be valid? As Jim Schaad already said, RFC 5752 talks about this issue when a CMS SignedData contains more than one SignerInfo. Russ On Sep 11, 2018, at 4:45 PM, Max Pala <M.Pala@cablelabs.com <mailto:M.Pala@cablelabs.com> > wrote: Hi All, I am working on a similar - but different - solution, in particular I solve the issue of (a) being able to combine more than one public key, (b) only one (actually two) OIDs required, and (c) simply the processing by re-utilizing the same data structures we have today. I particular, I define a “composite public key” and “composite signature”. The first one encodes in the key value’s BITSTRING the DER value of the SEQUENCE of public keys (each of which is a the subjectPublicKeyInfo structure) and uses a specific OID that identifies the public key type. The parameters of the compositeKey algorithm can be used to encode the keyUsage and the extendedKeyUsage for each of the keys in the composite key. The same approach is used for the “Composite Signature” case where the value of the signature is the DER representation of the SEQUENCE of signatures made with each of the keys. As soon as I have some spare time, I will submit the draft - maybe this could be discussed in Bangkok? This simple idea allows us to have all the other procedures related to PKIs work - this means we can combine ECC with RSA or with a Quantum-Resistant algorithm (when finally available and standardized). A step forward for the deployment of hybrid-PKIs where multiple Lagos for keys can be used to authenticate data, certs, revocation data, etc... we plan to use this in our infrastructures to provide a transitional path for post-Quantum transition and to further improve the algorithm-agility capability of PKIs. What do you think? Cheers, Max --- Cheers, Max On Sep 11, 2018, at 8:38 AM, Tim Hollebeek < <mailto:tim.hollebeek@digicert.com> tim.hollebeek@digicert.com> wrote: Unfortunately, “not every combination needs to be covered” introduces a lot of politics around choosing which combinations “need to be covered”, a subject on which inevitably not everyone agrees. I would rather avoid all those discussions and the unnecessary work they represent. I personally don’t think a single AlgID which implies a SEQUENCE of ALG IDs is an improvement over a SEQUENCE of ALG IDs, or its moral equivalent. For simple hybrid use cases, there is also a lot of value in having the classical algorithm ID being the same as it usually is, to allow easier interoperability with older systems that don’t understand the newer algorithms (and can blissfully ignore them). -Tim From: Santosh Chokhani < <mailto:santosh.chokhani@gmail.com> santosh.chokhani@gmail.com> Sent: Tuesday, September 11, 2018 10:29 AM To: Tim Hollebeek < <mailto:tim.hollebeek@digicert.com> tim.hollebeek@digicert.com>; 'Erik Andersen' < <mailto:era@x500.eu> era@x500.eu>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>; <mailto:x500standard@freelists.org> x500standard@freelists.org Subject: RE: [lamps] Double signatures Thanks Tim. There are ways to accommodate your concern. One way to handle this is defining a single Alg ID A which implies a SEQUENCE of ALG IDs and define the relying party rules in terms of its ability to process one or all ALG IDs. Another way to do this is not every combination needs to be covered and the user community defines its own Alg ID Xi which maps to a SEQUENCE of ALG IDs. From: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] On Behalf Of Tim Hollebeek Sent: Tuesday, September 11, 2018 10:03 AM To: Erik Andersen < <mailto:era@x500.eu> era@x500.eu>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>; <mailto:x500standard@freelists.org> x500standard@freelists.org Subject: Re: [lamps] Double signatures Doesn’t the combinatoric explosion render this completely impractical? You need N_c x N_pq algorithm identifiers just to handle the simple hybrid use case where a single classical algorithm is being used in conjunction with a single post-quantum algorithm. And there are people who want to use multiple post-quantum algorithms to hedge against potential yet to be discovered weaknesses in post-quantum algorithms. I’m not really looking forward to trying to allocate or manage O(N_c x N_pq^3) algorithm identifiers… -Tim From: Spasm < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org> On Behalf Of Erik Andersen Sent: Tuesday, September 11, 2018 3:10 AM To: 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>; <mailto:x500standard@freelists.org> x500standard@freelists.org Subject: Re: [lamps] Double signatures Hi Santosh, You have proposed something like this before. It still puzzling in my brain. As I understand, it requires that we define a particular algorithm that has a parameter that includes the things you suggest. It is worthy to be analysed. Erik Fra: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] På vegne af Santosh Chokhani Sendt: 10 September 2018 19:18 Til: 'Jim Schaad' < <mailto:ietf@augustcellars.com> ietf@augustcellars.com>; 'Ryan Sleevi' < <mailto:ryan-ietf@sleevi.com> ryan-ietf@sleevi.com>; <mailto:era@x500.eu> era@x500.eu Cc: 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>; <mailto:x500standard@freelists.org> x500standard@freelists.org Emne: Re: [lamps] Double signatures Why not let algorithm identifier dictate the number of signatures and their syntax? From: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, September 10, 2018 1:07 PM To: 'Ryan Sleevi' < <mailto:ryan-ietf@sleevi.com> ryan-ietf@sleevi.com>; <mailto:era@x500.eu> era@x500.eu Cc: 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>; <mailto:x500standard@freelists.org> 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 < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org> On Behalf Of Ryan Sleevi Sent: Monday, September 10, 2018 8:53 AM To: <mailto:era@x500.eu> era@x500.eu Cc: SPASM < <mailto:spasm@ietf.org> spasm@ietf.org>; <mailto:x500standard@freelists.org> x500standard@freelists.org Subject: Re: [lamps] Double signatures On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen < <mailto:era@x500.eu> 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> 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 <mailto:Spasm@ietf.org> Spasm@ietf.org <https://www.ietf.org/mailman/listinfo/spasm> https://www.ietf.org/mailman/listinfo/spasm
- [lamps] Double signatures Erik Andersen
- Re: [lamps] Double signatures Ryan Sleevi
- Re: [lamps] Double signatures Jim Schaad
- Re: [lamps] Double signatures Santosh Chokhani
- Re: [lamps] Double signatures Panos Kampanakis (pkampana)
- Re: [lamps] Double signatures Jim Schaad
- Re: [lamps] Double signatures Erik Andersen
- Re: [lamps] Double signatures Erik Andersen
- Re: [lamps] Double signatures Tim Hollebeek
- Re: [lamps] Double signatures Santosh Chokhani
- Re: [lamps] Double signatures Tim Hollebeek
- Re: [lamps] Double signatures Max Pala
- Re: [lamps] Double signatures Sean Turner
- Re: [lamps] Double signatures Russ Housley
- Re: [lamps] Double signatures Jim Schaad
- Re: [lamps] Double signatures Massimiliano Pala
- Re: [lamps] Double signatures Stephen Farrell
- Re: [lamps] Double signatures Santosh Chokhani
- Re: [lamps] Double signatures Erik Andersen
- Re: [lamps] Double signatures Erik Andersen
- Re: [lamps] [x500standard] SV: Double signatures Stiepan
- Re: [lamps] Double signatures Panos Kampanakis (pkampana)
- Re: [lamps] Double signatures Jim Schaad
- Re: [lamps] Double signatures Dr. Pala
- Re: [lamps] Double signatures Panos Kampanakis (pkampana)
- Re: [lamps] Double signatures Jim Schaad
- Re: [lamps] Double signatures Tim Hollebeek
- Re: [lamps] Double signatures Jim Schaad
- Re: [lamps] Double signatures Daniel Van Geest
- Re: [lamps] Double signatures Panos Kampanakis (pkampana)