Re: [lamps] Fixed the RFC 8994 / ACP Subject Alternative Name example - Re: struggling with CSRAttrs

[Esko Dijk <[e-mail]>]

Hi all,

‘Struggling’ is the right word. I noticed that in version -01 of the draft the section 5.1 example is using a differently formatted address than section 5.2, namely:

[e-mail]

why does this look different than typical RFC 8994 example addresses? (It has two ‘+’ characters, not one. And order of names 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.

For such examples with a very specific node ID (like ‘fd739fc23c3440112233445500000000’) in the CSR attributes 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 but it looks like BRSKI is then deviating from this recommendation and REQUIRES authentication. If not authenticated, the server can’t send the right node ID to the Pledge, right?  If that’s correct then it is worth pointing out in text with the example because otherwise for people using RFC 7030 as a reference it gets quite confusing.

Regards
Esko

From: Spasm <[e-mail]> On Behalf Of von Oheimb, David
Sent: Saturday, October 1, 2022 11:32
To: [e-mail]; [e-mail]
Subject: Re: [lamps] Fixed the RFC 8994 / ACP Subject Alternative Name example - Re: struggling with CSRAttrs

On Fri, 2022-09-30 at 23:29 +0200, Michael Richardson wrote:

David von Oheimb <[e-mail]<mailto:[e-mail]>> wrote:
    > I've added to our repo a little script and config using OpenSSL for
    > producing the extended and corrected example ASN.1 encoding:

I saw that, but it generates a CSR, not a CSRattributes :-)

sure, but CSRattrs are designed to have essentially the same structure as CSRs.
And unfortunately I don't have a better tool.

David