[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