IETF Logo Mail Archive

Re: [lamps] EST CSRATTRS specifying the SAN

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 05 July 2021 18:37 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 D3E463A0E28; Mon, 5 Jul 2021 11:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nUjah2De_yBs; Mon, 5 Jul 2021 11:37:40 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35513A0E00; Mon, 5 Jul 2021 11:37:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F277C38AA6; Mon, 5 Jul 2021 14:40:01 -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 HRqz178ZD3Rq; Mon, 5 Jul 2021 14:39:56 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D5DD38A15; Mon, 5 Jul 2021 14:39:56 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D7CC454; Mon, 5 Jul 2021 14:37:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: David von Oheimb <nl0@von-Oheimb.de>, Sean Turner <sean@sn3rd.com>, Eliot Lear <lear@lear.ch>, SPASM <spasm@ietf.org>, Max Pritikin <pritikin@cisco.com>, anima@ietf.org
In-Reply-To: <6e29b64d-0bc0-d129-beff-4072a482cfbd@von-Oheimb.de>
References: <83844291-5785-434E-8956-3FF81ECD761C@cisco.com> <9820.1618358856@localhost> <MW3PR11MB47462121627A10A62E006497DB369@MW3PR11MB4746.namprd11.prod.outlook.com> <26435.1623269725@localhost> <25C432F7-EDEE-4FEA-B871-5D7F9311BBF7@sn3rd.com> <6e29b64d-0bc0-d129-beff-4072a482cfbd@von-Oheimb.de>
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, 05 Jul 2021 14:37:31 -0400
Message-ID: <2219.1625510251@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/va-VeiK8BWiMC8N_Vrs1Qwowl9c>
Subject: Re: [lamps] EST CSRATTRS specifying the SAN
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, 05 Jul 2021 18:37:45 -0000

David von Oheimb <nl0@von-Oheimb.de> wrote:
    > would have been more apparent.

well, you just used ASN.1 we didn't understand to explain other ASN.1 we
didn't understand :-)

What I took away was that my interpretation was not quite right for getting a
explicit value.

    > Further, RFC 7030 section 4.5.2 does not cover the fact that names and
    > name components in a CSR may be part of not only various X.509
    > extensions such as SAN (which are to be encoded via the extra
    > indirection of the extensionRequest OID) but also of the subject
    > field/attribute of type (Distinguished)Name.

Could you construct an example? Perhaps we could slip it in as errata.

    > At least a more comprehensive example would have been very helpful to
    > clarify the details of the intended encoding, and likewise any serious
    > reference/example implementation, for instance in Cisco's libEST, which
    > has remained extremely sketchy regarding the csrattrs topic.

Are there examples in libest that we can use?
Is there unit test code in there that could be exercised to validate other examples?

Are we back to redoing this in JSON?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email