[lamps] RFC8994/8995 requirements for CSRattr

[Michael Richardson <[e-mail]>]

Hi, Toerless, Esko, Peter, Max, Thomas, Owen,

Please be aware that there is a virtual interim meeting for LAMPS tomorrow (Monday).
The details are at:
   https://datatracker.ietf.org/doc/agenda-interim-2021-lamps-02-lamps-01/

Use https://meetings.conf.meetecho.com/interim/?short=a4fd6373-c1d1-453c-9e2b-b17d9899d53e
at: Monday 2021-08-30 17:30 UTC

The topic is about the /csrattrs contents, and whether or not the Registrar
can specify a specific value for an attribute, or if it can only specify the
need for an attribute to be present.

I've made some slides explaining the RFC8994 / RFC8995 needs.
I believe that this probably affects acme-integrations as well, as only the
Registrar knows what (DNS) name it will populate for the pledge, but RFC8555
does not provide any out of band way for the a Registrar to specify SAN,
except for CSR.

I have made some slides, which will appear at the above link once the chairs
approve.  I have placed them at
http://www.sandelman.ca/tmp/csrattrs-requirements.pdf for the interim.
(Sorry, Russ, that this is so late)

Comments welcome.

I put four options in the slides:

1. fix RFC7030 CSRattrs to reflect our understanding
   (document to update 7030)

2. extend RFC7030 CSRattrs ASN.1 to create new mechansim to specify value
   (document to update 7030)

3. obsolete ASN.1 CSRattrs, create new mechanism, based in CBOR and/or JSON
   (new document in LAMPS)

4. have RFC8994/8995 ignore CSRattrs, create new BRSKI-specific mechanism to
   specify SAN
   (new document in ANIMA)

Perhaps you can think of others.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide