IETF Logo Mail Archive

Re: [lamps] EST CSRATTRS specifying the SAN

David von Oheimb <nl0@von-Oheimb.de> Wed, 07 July 2021 07:33 UTC

Return-Path: <nl0@von-Oheimb.de>
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 762473A09FD; Wed, 7 Jul 2021 00:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.233
X-Spam-Level:
X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 UYa-8UyO_eoA; Wed, 7 Jul 2021 00:33:20 -0700 (PDT)
Received: from server8.webgo24.de (server8.webgo24.de [185.30.32.8]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0008E3A09FA; Wed, 7 Jul 2021 00:33:18 -0700 (PDT)
Received: from [192.168.178.115] (dynamic-095-117-085-028.95.117.pool.telefonica.de [95.117.85.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server8.webgo24.de (Postfix) with ESMTPSA id 6BA5442265F; Wed, 7 Jul 2021 09:33:15 +0200 (CEST)
From: David von Oheimb <nl0@von-Oheimb.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Russ Housley <housley@vigilsec.com>, Sean Turner <sean@sn3rd.com>, Eliot Lear <lear@lear.ch>
Cc: SPASM <spasm@ietf.org>, anima@ietf.org
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> <2219.1625510251@localhost> <bf91794a-d8d9-6319-627d-e83fa8b2b399@von-Oheimb.de>
Message-ID: <667059c8-1e2b-7896-df05-b08f3433a63e@von-Oheimb.de>
Date: Wed, 07 Jul 2021 09:33:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <bf91794a-d8d9-6319-627d-e83fa8b2b399@von-Oheimb.de>
Content-Type: multipart/alternative; boundary="------------89EBB7ED6ABDA58C20264102"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/G03dwVRzaG4_Tt-jfhing-Fh6Kk>
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: Wed, 07 Jul 2021 07:33:25 -0000

On 05.07.21 23:49, David von Oheimb wrote:
> I fear that RFC 7030 does not support expressing requested contents of
> the subject field.
Thinking more about it,
I'm meanwhile pretty sure that giving a concrete complete value for the
subject DistinguishedName (DN) cannot be done in that "wonderful"
Attribute structure, simply because there is no OID for the subject field.
Yet what can be done is to (ab-)use one or more of those Attribute
structures as elements of CsrAttrs to specify concrete values for
*individual sub-components* of the subject DN,
namely single attributes of RDNs, e.g.,

             SEQUENCE {
               OBJECT IDENTIFIER commonName (2 5 4 3)
               UTF8String "myHostname"
               }

and

             SEQUENCE {
               OBJECT IDENTIFIER serialNumber (2 5 4 5)
               PrintableString "JABA1234'
               }

Note that in this way one cannot express a particular desired
*structure* of RDNs for the subject DN.

(BTW, the general structure of DNs being a sequence or RDNs, each of
which can contain a set of name attributes, see
https://datatracker.ietf.org/doc/html/rfc2253#section-2
is a rather weird thing that is hardly understood and not always
implemented correctly/completely, but that's a different story).

    David

v2.23.0 | Report a Bug | By Email