Hi Michael,
Why can't the RA signal to the CA whatever things it things should
be included in the CA, in addition to the goo provided in the client's
CSR? If the Registrar knows the name then why can't it provide it to
the CA. It will be providing the CSR to the CA, on behalf of the client,
so why can't it say "oh by the way, add this name for the pledge...."
Why don't you want to define _that_ signalling instead of overloading
a different protocol?
Dan.
On 8/29/21 11:11 AM, Michael Richardson wrote:
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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Spasm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spasm
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
