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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
