[saag] META Re: PKIX and related RFCs - definition of Key Packages
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 17 June 2021 21:19 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE103A2E7C for <saag@ietfa.amsl.com>; Thu, 17 Jun 2021 14:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.38
X-Spam-Level:
X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 DId351adPOvS for <saag@ietfa.amsl.com>; Thu, 17 Jun 2021 14:19:46 -0700 (PDT)
Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 EAFA53A2E7D for <saag@ietf.org>; Thu, 17 Jun 2021 14:19:45 -0700 (PDT)
Received: by mail-qk1-f169.google.com with SMTP id f70so5698644qke.13 for <saag@ietf.org>; Thu, 17 Jun 2021 14:19:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=6NuDJtGqK/UwB5IGQuexvPAPD7EvDY4TE82XLaUqRx8=; b=J74zgqGPAs33g+uFy1fBzy8yCrcZVe2hy/huJjLr+HOoVZ1ZTTQxHX5oMc8QxZJ3a3 9+rh6sX7epSUMtFwXxuJ1jVSEU9FSvirpksTl8xThuqiTma58LHZB+KbYQ9KLqc61oRK PV7iRYePyWRuxTrYhskUFtoancCkv+7RpbiD4/4tRCDBpMs86UQfUw6Jsaip9NqIHHin /z7z/eCVJGTVfovyQNcS4o127p4u4xPoqlT1qWLthSfnBkZ/YHIXQ66n6kZlrmyZWekY /tR1lN0/cgDFx9xbFsFwktprBYgQxy8C/we3KmbenB9nKkHNtI2jGn//gjBDMtzNn489 jXCA==
X-Gm-Message-State: AOAM531z/kHJisfcrqWCrt7ocJEGEoAdLHxVbYmkvxKAHFEaLY5ITSh4 FDkslBXpwshp27oUKvz0Qt2Q1tXk8J9q1Pky5tarN2UEhDM=
X-Received: by 2002:a25:6910:: with SMTP id e16mt9192703ybc.523.1623964784600; Thu, 17 Jun 2021 14:19:44 -0700 (PDT)
MIME-Version: 1.0
References: <B8006164-51AD-4B3B-9CE7-83B0574294F8@ll.mit.edu>
In-Reply-To: <B8006164-51AD-4B3B-9CE7-83B0574294F8@ll.mit.edu>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 17 Jun 2021 17:19:34 -0400
Message-ID: <CAMm+LwiLHWzzva=yhJ-=b9b4rUBC1oa5HPyAAm5qkv1jPgf-FQ@mail.gmail.com>
Cc: "saag@ietf.org" <saag@ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f39e505c4fcc455"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/MPScZKLIL10P1Eg5Ics2tzG8idE>
Subject: [saag] META Re: PKIX and related RFCs - definition of Key Packages
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2021 21:19:48 -0000
I agree with much of Uri's frustration here. My concern is the meta level. If LAMPS is going to ever close, we have to make sure we are not going to need something similar in future. Which means that we need to define what is required to specify a cryptographic algorithm so it is available for use with IETF protocols. Note that adding an algorithm to a registry does not mean it is approved for use by a particular protocol. CMS serves a much wider audience than S/MIME. PKIX, a wider audience than either the WebPKI or PKI in general. Same for JOSE, XML Signature and Encryption, etc. etc. So I conclude that one of the exit criteria for LAMPS should be a document describing the list of things that need to be specified so that an algorithm can be used in various specific IETF protocols and conversely, what applications using the IETF maintained IANA registries can expect. I do not want to get into discussions of why the decisions of some working group ten years ago on algorithm requirements should bind some other group doing something different today. HTTP is not based on MIME but it uses the same IANA registry. That is the correct approach in my view. Going forward, I see no reason why it should be necessary to specify separate identifiers for the use of a particular algorithm in every different application protocol. The ASN.1 world is going to need OIDs for quite some time and the JOSE world is going to be needing text based labels. The XML world consumes URIs but there is no reason we couldn't specify a URN prefix to the JOSE labels and use that to avoid further maintenance issues. TLS and IPSEC both operate at a layer that is sufficiently deep that we should just let them do their own thing. And PEM probably isn't much of a concern going forward.
- [saag] PKIX and related RFCs - definition of Key … Blumenthal, Uri - 0553 - MITLL
- Re: [saag] PKIX and related RFCs - definition of … Peter Gutmann
- Re: [saag] PKIX and related RFCs - definition of … Blumenthal, Uri - 0553 - MITLL
- Re: [saag] PKIX and related RFCs - definition of … Peter Gutmann
- Re: [saag] PKIX and related RFCs - definition of … Russ Housley
- [saag] META Re: PKIX and related RFCs - definitio… Phillip Hallam-Baker
- Re: [saag] [lamps] META Re: PKIX and related RFCs… Blumenthal, Uri - 0553 - MITLL