Re: [lamps] RFC8994/8995 requirements for CSRattr

   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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> 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