Subject: [Anima] RFC8994/8995 requirements for CSRattr

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Aug 2021 14:11:32 -0400

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-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Dan Harkins <[email-masked]>
Date: Sun, 29 Aug 2021 16:31:35 -0700

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:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> 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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Aug 2021 03:21:46 -0400

> be included in the CA, in addition to the goo provided in the client's

I don't know. Why can't it?  What protocol can it use that is well deployed?

    >   Why don't you want to define _that_ signalling instead of overloading

I'd love to define that protocol.
But, we thought CSRattrs was that protocol.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 30 Aug 2021 00:35:30 -0700

> I don't know. Why can't it?  What protocol can it use that is well deployed?

   The RA can do that signalling. You just need to define the protocol.

> But, we thought CSRattrs was that protocol.

   Why did you think that? I can see a "it's there and we can tweak it 
to do this
weird thing we want to do" but I don't understand why one would think 
that CSRattrs
was designed for that.

   If the RA knows what information the CA needs in order to construct a 
certificate
then it should just tell the CA.

   Dan.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Aug 2021 09:40:46 +0200

I would suggest that it helps in these cases to back up to the scenarios 
we care to address, and the likelihood of success.  In some cases, it 
will be possible to coordinate development with the endpoints and 
sometimes with the CAs.  The CAs may not be strongly motivated to 
standardize an out-of-band/underlay RA/CA interface**- some already have 
proprietary versions, and may like that with the hope of locking in the 
endpoints along the way.

Eliot