Re: [lamps] EST CSRATTRS specifying the SAN

David von Oheimb <nl0@von-Oheimb.de> Wed, 07 July 2021 13:02 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 86DFA3A141A; Wed, 7 Jul 2021 06:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level:
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, 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 9XllsstIw2GF; Wed, 7 Jul 2021 06:02:41 -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 172A93A1419; Wed, 7 Jul 2021 06:02:40 -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 763AB422223; Wed, 7 Jul 2021 15:02:37 +0200 (CEST)
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, 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" <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> <667059c8-1e2b-7896-df05-b08f3433a63e@von-Oheimb.de> <A30A91FC-4737-42DC-8699-32CCBA5EA371@ll.mit.edu>
From: David von Oheimb <nl0@von-Oheimb.de>
Message-ID: <6334a770-f202-49d4-34c8-5e44b4e56e62@von-Oheimb.de>
Date: Wed, 07 Jul 2021 15:02:35 +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: <A30A91FC-4737-42DC-8699-32CCBA5EA371@ll.mit.edu>
Content-Type: multipart/alternative; boundary="------------6C88CA8C7FB3CCE71377AE8F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/JIIOwWrUEkk4CreSArcAMA1Mnt0>
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 13:02:46 -0000

Well, the weird structure of (R)DNs cannot be avoided - it's part of
LDAPv3 and thus of X.509.
This stuff is repeated, e.g., in
https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.4
Yet many users simply ignore the fact that each RDN is a set and assume
it contains just one name attribute - which works in most cases.

    David

On 07.07.21 14:43, Blumenthal, Uri - 0553 - MITLL wrote:
>
> 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.
>
> At least the above is _implementable_.
>
> (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).
>
> Is that “weird thing” even necessary?  I feel like dumping a lot of
> accumulated crust and crud that proved to be more trouble than it
> seems worth…
>
>  
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm