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

[Michael Richardson <[e-mail]>]

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