Re: [lamps] RFC8994/8995 requirements for CSRattr

[David von Oheimb <[e-mail]>]

In my view, the idea recently brought up here (namely, to open a further
channel between RA(s) and CA(s)
besides the regular enrollment protocol just to be able to convey some
extra data to insert in the certificate)
is not good at all. It would be needlessly cumbersome and most likely
would not become generally accepted.

Instead, the extra data should be communicated as part of the (possibly
corrected/extended) existing enrollment protocol.
As far as EST is concerned, I'm glad to see that it has been decided to
update/correct the CSRattrs mechanism of RFC 7030.

    David

On 30.08.21 09:40, Eliot Lear wrote:
>
> 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
>

On 30.08.21 01:31, Dan Harkins wrote:
>
>   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.