[lamps] new document draft-richardson-lamps-rfc7030-csrattrs-00.txt
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 25 October 2021 16:00 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 A6AC13A0B0A for <spasm@ietfa.amsl.com>; Mon, 25 Oct 2021 09:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FVzuN4rS4F7S for <spasm@ietfa.amsl.com>; Mon, 25 Oct 2021 09:00:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990CC3A0653 for <spasm@ietf.org>; Mon, 25 Oct 2021 09:00:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 37AD8180AC for <spasm@ietf.org>; Mon, 25 Oct 2021 12:01:08 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rcJ6aYQBigja for <spasm@ietf.org>; Mon, 25 Oct 2021 12:01:04 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BB26F1805E for <spasm@ietf.org>; Mon, 25 Oct 2021 12:01:04 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7CBE6AC7 for <spasm@ietf.org>; Mon, 25 Oct 2021 12:00:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: spasm@ietf.org
In-Reply-To: <163490631266.2790.13198540371548098259@ietfa.amsl.com>
References: <163490631266.2790.13198540371548098259@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 25 Oct 2021 12:00:05 -0400
Message-ID: <24967.1635177605@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/obtrt5D2kAbj-letsX2B6u-KGzk>
Subject: [lamps] new document draft-richardson-lamps-rfc7030-csrattrs-00.txt
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, 25 Oct 2021 16:00:16 -0000
As agreed at the late August virtual interim, an initial -00/-01 drafty draft has been posted to the DT. The only difference between -00 and -01 is fixing some non-breaking spaces that got into a code display. There are two options in the document right now. I think that we tending towards option two, although it has less formalism so far. Option two has a display that actually contains the core of the proposal: OBJECT challengePassword SEQUENCE OBJECT subjectAltName SET OBJECT someACPgoo SEQUENCE OBJECT id-ecPublicKey SET OBJECT secp384r1 OBJECT ecdsa-with-SHA384 That places were we want to put a value would simply have a SEQ with a attribute/set-of-values. That's what *I* had understood from the ASN.1. My view is that at this point that we just need to fix the ASN.1 to reflect this possibility. I don't really know how to do that. There are some private threads among the authors, but it's time to have the discussion on the list. Name: draft-richardson-lamps-rfc7030-csrattrs Revision: 01 Title: Clarification of RFC7030 CSR Attributes definition Document date: 2021-10-25 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-richardson-lamps-rfc7030-csrattrs-01.txt Status: https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030-csrattrs/ Html: https://www.ietf.org/archive/id/draft-richardson-lamps-rfc7030-csrattrs-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030-csrattrs Abstract: Enrollment over Secure Transport (EST) is ambiguous in specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates EST and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values that the server expects the client to include in its CSR request. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [lamps] new document draft-richardson-lamps-rfc70… Michael Richardson