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.EliotOn 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.
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
