Re: [lamps] [EXTERNAL] X.510
"Erik Andersen" <era@x500.eu> Mon, 14 October 2019 12:29 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 994C1120274 for <spasm@ietfa.amsl.com>; Mon, 14 Oct 2019 05:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.397
X-Spam-Level:
X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=x500.eu
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 paUW8W1vX8eh for <spasm@ietfa.amsl.com>; Mon, 14 Oct 2019 05:29:37 -0700 (PDT)
Received: from outscan1.mf.dandomain.dk (outscan1.mf.dandomain.dk [212.237.249.58]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5599E1202DD for <spasm@ietf.org>; Mon, 14 Oct 2019 05:29:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by outscan1.mf.dandomain.dk (Postfix) with ESMTP id A646A4054A18 for <spasm@ietf.org>; Mon, 14 Oct 2019 14:29:34 +0200 (CEST)
Received: from outscan1.mf.dandomain.dk ([127.0.0.1]) by localhost (outscan1.mf.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2ab0C9UvmRK for <spasm@ietf.org>; Mon, 14 Oct 2019 14:29:33 +0200 (CEST)
Received: from mail-proxy.dandomain.dk (dilvs03.dandomain.net [194.150.112.64]) by outscan1.mf.dandomain.dk (Postfix) with ESMTPA id 573E34054A1D for <spasm@ietf.org>; Mon, 14 Oct 2019 14:29:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x500.eu; s=dandomain; t=1571056173; bh=HS/ic/3uRN4f5+mgTV2h8laG96DvFQzBQkvkYlYNc1s=; h=From:To:References:In-Reply-To:Subject:Date:From; b=cHGshQA8vNtBm6u9CpZaNXlk0nBgnOQIN+RBdpT1BK2BxK4e0wJW2ub9m7Nz9QEY9 wyG4GtKp0AAL3kXGvJfQJKFiC6dnUijGOTetkrg21K+uDv9WnUFYZBTzXQpGqlwN4n CuUWPzSL7Fdoj3Sa3yMl4hv75WUXjfIQB9r/MdXQEbqp8C6KXMoo/09mhXgpb7BqjI xx9zlGKQP5DdwiQAteyao9dYPA4wFK6typJ+i8SQVcT+ZjG+Mv6Ykjmp2me2cPcRex IIsqcqWbvTsSjwy9nrVPju5/ZsH7bEcGBvAHCXG2HQ0yhmSeUJxP0w/iJK1vQXJ/J0 qmHGG3PqMy3Dg==
From: Erik Andersen <era@x500.eu>
To: 'LAMPS' <spasm@ietf.org>
References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> <002201d572b2$0815f6e0$1841e4a0$@x500.eu> <MN2PR11MB37106863E5A2CE52D8125EE39B9D0@MN2PR11MB3710.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB37106863E5A2CE52D8125EE39B9D0@MN2PR11MB3710.namprd11.prod.outlook.com>
Date: Mon, 14 Oct 2019 14:29:32 +0200
Message-ID: <000601d5828b$089cdaa0$19d68fe0$@x500.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQISoDp2LBZNpXW83TH/US3RFiUrOAFnm8W/AmSLsb4Byz/iDqaxzZ1Q
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/INFGkrSM8D-XXHtU_tP_ubb5P_4>
Subject: Re: [lamps] [EXTERNAL] X.510
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: Mon, 14 Oct 2019 12:29:41 -0000
Hi Mike, Jim, Russ and others, In X.509 and X.510 we have mostly been concentrating on establishing migration paths. Using multiple algorithms for added security was not the scope, although some of our ASN.1 construct could be used for that purpose. In our work we have considered the basic public-key certificate structure sacred in order not to cause backward compatibility problems. That is why we adopted the ISARA approach. We did not dare to add duplicate signatures on the certificate itself. We would then also need to duplicate the signature component in order to protect all the used digital signature algorithms. That would break a lot of applications. The ISARA solution was added to X.509, not X.510. X.509 together with the rest of the X.500 series have been approved, the master is with the ITU-T editing team and therefore out of my jurisdictions. As far as public-key certificates, attribute certificates, CRLs and authorization and validation lists, it is too late to make any changes. When using double algorithms and signature, it is important that the alternative algorithms and signature can be ignored by a legacy entity. X.510, which is not yet an officially part of the X.500 series, is getting close to completion. In clause 6.4.1 we have a MULTY-SIGNED parameterized data type that seems to do the same thing as the sa-CompositeSignature object specified in the Internet Draft. This MULTY-SIGNED data type is an expansion of the SIGNED data type. It appears to me we have a general problem with the use of ASN.1 between the two organizations. The Internet draft make reference to ASN.1 information object classes specified in RFC 5912. This RFC redefine a number of information object classes, such as ATTRIBUTE, MATCHING-RULE, EXTENSION and ALGORITHM and it adds a lot of new information object classes not used in the by X.509 or X.510. Alignment will probably require quite extensive negotiation between the two organizations. Best regards, Erik -----Oprindelig meddelelse----- Fra: Mike Ounsworth [mailto:Mike.Ounsworth@entrustdatacard.com] Sendt: 01 October 2019 17:23 Til: Erik Andersen <era@x500.eu>; 'LAMPS' <spasm@ietf.org> Emne: RE: [lamps] [EXTERNAL] X.510 Hi Erik, This is joint feedback on X.510 from the group of authors who worked on the composite pubic keys and signatures draft (https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01) and some overlap with the authors of the hybrid certificates draft (https://tools.ietf.org/html/draft-truskovsky-lamps-pq-hybrid-x509-01) which is now being pursued at ITU-T by ISARA. 1. X.510 section 6 defines MultiplePublicKeyAlgo identifiers and params, but seems to be missing a definition of the public keys themselves. If the idea is to concatenate multiple public keys into the single existing octet string, it's probably important to define that encoding. See our draft for how we thought to define that structure: https://tools.ietf.org/html/draft-ounsworth-pq-composite-sigs-01#section-2.3 . 2. X.510 Annex G: the mechanism you define relies on the use of ASN.1 extension marks, which were introduced to the SIGNED structure in X.509 rev 7 (2012), and are not included in the ASN.1 structures of the X.509 profile in IETF RFC5280 (2008). I see that you address that on p. 72 in the paragraph "If extension marks are not supported", basically saying to use the MultiplePublicKey definitions from section 6. This is not a problem for your draft, but we wanted to point out on this mailing list that IETF and WebPKI can't use the mechanism proposed in Annex G without updating RFC5280 and relying implementations to support ASN.1 extension marks. 3. For both mechanisms (section 6, and Annex G), have you thought about stripping attacks, where say the attacker cracks the weaker of the two signatures and then replaces the other public key with one that he controls? I suppose this needs to be addressed at the protocol layer, and therefore is out of scope for section 6 / annex G, but we still wanted to mention it on this mailing list. 4. Perhaps it makes sense to harmonize the ASN.1 structures between X.510 and our IETF draft(s). Would you be open to joining a phone call with our author group? -Mike Ounsworth, Representing the authors of draft-ounsworth-pq-composite-sigs -----Original Message----- From: Spasm <spasm-bounces@ietf.org> On Behalf Of Erik Andersen Sent: Tuesday, September 24, 2019 3:28 AM To: 'LAMPS' <spasm@ietf.org> Cc: Mark Pecen <mark.pecen@isara.com>; Jean-Paul LEMAIRE <jean-paul.lemaire@univ-paris-diderot.fr> Subject: Re: [lamps] [EXTERNAL] X.510 Hi Mike, A good point. Having multiple algorithms for added security and not just for migration is not really considered in draft X.510, which could be a miss. We will see if we can get that aspect into document during its final ballot round where in principle only editorials are allowed. Anyway, we will probably need an edition 2 quite quickly. Best regards, Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] På vegne af Mike Ounsworth Sendt: 24 September 2019 05:51 Til: Erik Andersen <era@x500.eu>; LAMPS <spasm@ietf.org> Emne: Re: [lamps] [EXTERNAL] X.510 Hi Erik, I found your slides https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dynamic NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN.pd f, explaining the rationale behind X.510. In it, you say: * A back level recipient will ignore the alternative algorithm, but validate according to the native one * An advanced recipient will validate according to the alternative algorithm In attending post-quantum conferences, for example the NIST PQC, there is a strong call for "hybrid" modes where *both* algorithms are validated because we don't fully trust the new stuff yet. So this may not be simply a migration issue, but a more long-term issue of combining algorithms for increased security. Do you have an opinion on whether X.510 in its current form would be appropriate for hybrid modes, and whether your language should be adjusted to be "native algorithm and alt algorithm" as opposed to your current "native algorithm or alt algorithm" ? - - - Mike Ounsworth | Office: +1 (613) 270-2873 From: Spasm <spasm-bounces@ietf.org> On Behalf Of Erik Andersen Sent: Saturday, September 21, 2019 8:35 AM To: LAMPS <spasm@ietf.org> Subject: [EXTERNAL][lamps] X.510 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________________ Within ITU-T and ISO we have developed a new specification, Rec. ITU-T X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a link to | it https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=0. We expect to complete it by March 2020. Any comment any of you might have will be highly appreciated. Best regards, Erik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
- [lamps] X.510 Erik Andersen
- Re: [lamps] X.510 Russ Housley
- Re: [lamps] [EXTERNAL] X.510 Mike Ounsworth
- Re: [lamps] [EXTERNAL] X.510 Erik Andersen
- Re: [lamps] [EXTERNAL] X.510 Mike Ounsworth
- Re: [lamps] [EXTERNAL] X.510 Erik Andersen
- Re: [lamps] [EXTERNAL] X.510 Erik Andersen