From nobody Wed Oct 27 16:26:31 2021
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 888093A085A
 for <spasm@ietfa.amsl.com>; Wed, 27 Oct 2021 16:26:29 -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 ootyMILEJBAp for <spasm@ietfa.amsl.com>;
 Wed, 27 Oct 2021 16:26:25 -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 12F373A0856
 for <spasm@ietf.org>; Wed, 27 Oct 2021 16:26:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by tuna.sandelman.ca (Postfix) with ESMTP id 0EEEB18022
 for <spasm@ietf.org>; Wed, 27 Oct 2021 19:27:31 -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 SAgKSef10xPi for <spasm@ietf.org>;
 Wed, 27 Oct 2021 19:27:30 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21])
 by tuna.sandelman.ca (Postfix) with ESMTP id 929061801B
 for <spasm@ietf.org>; Wed, 27 Oct 2021 19:27:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1])
 by sandelman.ca (Postfix) with ESMTP id A4B7C585
 for <spasm@ietf.org>; Wed, 27 Oct 2021 19:26:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: spasm@ietf.org
X-Attribution: mcr
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: Wed, 27 Oct 2021 19:26:22 -0400
Message-ID: <27097.1635377182@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Dx7RYAXB7fbnc9eJV2zaVOVtzcc>
Subject: [lamps] rfc7030 CSR clarification ideas
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, 27 Oct 2021 23:26:30 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Subsequent to posting draft-richardson-lamps-rfc7030-csrattrs-01 on Monday,
David has clarified a few options with commit:
  https://github.com/mcr/lamps-rfc7030-csrattrs/commit/01f6949b880dd6269d5e=
886113486d056a42ebc1

in a number of the proposals, an explicit "Name" field is included in the a=
ttributes.

My understanding from RFC5280, is that the SubjectAltName is an extension a=
nd
it is not contained with a "Name" object.  In particular, section 4.2.1.6 of
RFC5280 says:


   GeneralName ::=3D CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,

so in fact a "Name" is allowed inside a SubjectAltName, and not the other w=
ay
around.

Pretty much all of the cases where we think that a Registrar needs to speci=
fy
a name to the client, it's some kind of SubjectAltName.  Often rfc822Name
or otherName (in the case of RFC8994/ACP).

So I think that we could consider all the options that David and others have
proposed, if we included a GeneralName rather than a Name?

Are there use cases (particularly given draft-ietf-uta-rfc6125bis-03 aka
draft-ietf-uta-use-san aka draft-rsalz-use-san) where we actually will need
to specify the SubjectDN... GOING FORWARD?

=2D-
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T consulti=
ng )
           Sandelman Software Works Inc, Ottawa and Worldwide





--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmF54B4ACgkQgItw+93Q
3WUh9wgAtsO5hpuCKxl5XgfUJtj2H4o3TlpbU288A6E/O9YqacnFDUmPoE1KP5ss
/mOVIHglm8wjg2vJWe+Pcpqz1U4c4l6KzLOQKldoR7atfYtNCFW++pFcDu4NFkjn
vGfGISLnD7ppHbuj/i6/0nmlqsT59bGHc++7xSO7ZHJPzxmkmiUNISjxv5cAnJop
TqvBuxmXvLSW+4PGrfAYHPY0gLPWQuWA8Rkwu2ARCb6nJzfZQyRFKIZjky50lNJ7
aYI+mtzjgd4LDpFhMWF55jWT7C1cV2Jiue4G1kQc83LG4adC+Vdz8MYVrawzFv6B
4B6JvMfrq7vkYZt4hGZWQJFYIGNRjQ==
=T/0F
-----END PGP SIGNATURE-----
--=-=-=--

