Re: [lamps] RFC8994/8995 requirements for CSRattr

[Eliot Lear <[e-mail]>]

David,

I mention that point because we already done this in one case with a CA, 
and my concern is that our code will bloat as we have to customize to 
other CAs.  It's a matter of whether you think you can influence the end 
devices or the CAs, and there are a lot more of the former than the 
latter.  I really don't have a crystal ball here.  If we can get code 
implemented on clients, keeping this to the RAs and endpoints would be 
great.  But that means that the client interfaces all need the code.  
And today, it's simply not there for many of them.  They have either 
ruby or python or go and a bit of devkit to match.

Eliot


On 01.09.21 15:20, David von Oheimb wrote:
>
> 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.
>
>