From nobody Sat Jan 28 00:06:23 2023 Return-Path: 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 36FB8C1526E9 for ; Sat, 28 Jan 2023 00:06:21 -0800 (PST) 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k36eMdHYc8h9 for ; Sat, 28 Jan 2023 00:06:20 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2330C14CF0D for ; Sat, 28 Jan 2023 00:06:19 -0800 (PST) Received: from dyas.sandelman.ca (unknown [77.241.232.28]) by relay.sandelman.ca (Postfix) with ESMTPS id CADD71F4A5; Sat, 28 Jan 2023 08:06:16 +0000 (UTC) Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 4A517A1820; Fri, 27 Jan 2023 18:36:14 -0500 (EST) Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 47EB3A17E1; Fri, 27 Jan 2023 18:36:14 -0500 (EST) From: Michael Richardson To: Esko Dijk cc: "von Oheimb\, David" , "spasm\@ietf.org" In-reply-to: References: <12352.1657505901@localhost> <563732.1659120308@dooku> <36c409c2-ab92-4ec2-6f1e-235652a243d9@siemens.com> <3758.1659557693@localhost> <399c3a1e-ee28-cc85-6e6a-cee210e70753@siemens.com> <19f4388a-49e1-d14e-2463-e9f0e181c2ea@siemens.com> <997117.1664573368@dooku> Comments: In-reply-to Esko Dijk message dated "Mon, 21 Nov 2022 10:41:43 +0000." X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Fri, 27 Jan 2023 18:36:14 -0500 Message-ID: <1345183.1674862574@dyas> Archived-At: Subject: Re: [lamps] Fixed the RFC 8994 / ACP Subject Alternative Name example - Re: struggling with CSRAttrs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2023 08:06:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm trying to clean up old emails, and I didn't realize this one wasn't abo= ut ASN.1 goo. Esko Dijk wrote: > =E2=80=98Struggling=E2=80=99 is the right word. I noticed that in ver= sion -01 of the > draft the section 5.1 example is using a differently formatted address > than section 5.2, namely: > rfc8994+fd739fc23c3440112233445500000000+@acp.example.com Huh. > why does this look different than typical RFC 8994 example addresses? > (It has two =E2=80=98+=E2=80=99 characters, not one. And order of nam= es is reversed?) > Why not use the standard address example from RFC 8994 to make it > easier to understand? Or is there a particular reason for this > formatting. I guess that I didn't notice that when we went from rfc822Name to otherName, that we lose the rfc8994+! My code says: sprintf("rfc%s+%s+%s@%s", SystemVariable.string(:rfc_ACP) || "8994", acp_address.to_hex, SystemVariable.acp_rsub, SystemVariable.acp_domain) So, the first RFC8994+ is superfluous from reading RFC8994 section 6.2.2. When rsub was on the left, it seemed like we should include the + even if rsub was empty. Now that it's on the right of the @, it seems that probably we shouldn't do that if they are nil. I will fix the example. > For such examples with a very specific node ID (like > =E2=80=98fd739fc23c3440112233445500000000=E2=80=99) in the CSR attrib= utes it may be > good to point out that the BRSKI client (or, EST client) needs to be > authenticated to the server at the time of requesting the CSR > attributes. > In general RFC 7030 says the client SHOULD NOT require > authentication to request the attributes To request them, yeah hmmm. What the use case? > but it looks like BRSKI is > then deviating from this recommendation and REQUIRES authentication. = If > not authenticated, the server can=E2=80=99t send the right node ID to= the > Pledge, right? If that=E2=80=99s correct then it is worth pointing o= ut in text > with the example because otherwise for people using RFC 7030 as a > reference it gets quite confusing. Yes, exactly. The get /csrattrs commits the Registrar to allocating a specific AcpNodeNam= e. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmPUX+0ACgkQlUzhVv38 QpBP6Af/YYH0ZtFvfT81zvQARezzifZpi8kfXNpyu7WnGwUFaAxzYfcUE7UOAfeB uTRBkv2UTSP7/uGDzrsjFU/MZI9pALUn2gbTFc+G66AhwOQYAH8XmAlDC/Yw9gWI EYqDq7W7O0kjY0z1GAyMNtqNbrnRN5gqt+Sf5TKPwUwl+5Pxn2+INeAE0N6wWFuN H/+LlHpgsizr/Sg5L+L9x7GlJm5jodnt0GxvVyYX1GfXMKU+NIbaQ1tKo5M7/h6h QlYxIJxSaNrEj/pp4i7IB8VeMho8u/G5G1jVU7Ja0tdA6iE1qfTEWYvS4rb4/yZM 9ritNTDalZ7kcEJ1od2u1DKpAuYIwg== =vbJB -----END PGP SIGNATURE----- --=-=-=--