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

[Esko Dijk <[e-mail]>]

Thanks Michael for the clarifications,

> Yes, exactly.
> The get /csrattrs commits the Registrar to allocating a specific AcpNodeName.

My reasoning was that the Registrar could only allocate a specific AcpNodeName if it would know the identity of the EST client. (So, TLS authentication is required.)
Suppose the client was anonymous, and then a second anonymous client connects, or the same client reconnects, how would the Registrar distinguish clients and allocate the right AcpNodeName again?
Or maybe that's not important in practice. The Registrar could also return a '0' as 'acp-address' part in that case.


>    > In general RFC 7030 says the client SHOULD NOT require
>    > authentication to request the attributes
>
>To request them, yeah hmmm.
>What the use case?

I'm just pointing out that for people not very deep into this topic, it becomes confusing quite quickly. So I read that a client preferably doesn't require authentication to read the CSR attributes, but on the other hand I read implicitly in the new draft that the EST server require authentication to give back the correct information for this request.  And that's not adding up.  And nowhere it's explained how & why.

I don't know if there's any use case for doing an unauthenticated request to get 'CSR attributes' and then authenticating later on to do the 'enroll' request; maybe a privacy-sensitive EST client that shops around across multiple EST servers to see which one provides a "CSR attributes" answer that it can understand or that optimally complies with its local policies?
But in the provided ACP case that's clearly not going to work and hence we should point out that the client MUST be authenticated for this example to work at all.

Regards
Esko


-----Original Message-----
From: Michael Richardson <[e-mail]> 
Sent: Saturday, January 28, 2023 00:36
To: Esko Dijk <[e-mail]>
Cc: von Oheimb, David <[e-mail]>; [e-mail]
Subject: Re: [lamps] Fixed the RFC 8994 / ACP Subject Alternative Name example - Re: struggling with CSRAttrs


I'm trying to clean up old emails, and I didn't realize this one wasn't about
ASN.1 goo.

Esko Dijk <[e-mail]> wrote:

    > ‘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]

Huh.

    > 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.

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
    > ‘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

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’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.

Yes, exactly.
The get /csrattrs commits the Registrar to allocating a specific AcpNodeName.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-