Hi David,Good way to have described the situation, and the one comment you added about e2e validation of EE<->CA to me is something that seems worthy of discussion.
Eliot On 01.09.21 15:47, David von Oheimb wrote:
Elliot,good point that modifying things on the RA-CA channel affects fewer implementations/devices than updates on the EE-RA channel.A further way to avoid opening a second channel between the RA and CA is not to augment the EE-RA channel is to improve the existing RA-CA channel in a way that is already covered by standards.For instance, when using CMP or CMS in this channel, the RA can inject new CSR fields (or modify anything in the CSR) as follows. The RA (Registrar) verifies the proof-of-origin and proof-of-possession of the CSR received from the EE (Pledge). The RA builds up a new CSR with all the contents it wishes to take over and adds/modifies whatever it wishes. The RA signs this CSR (which is on behalf of the EE) with its own key material, asserting that it verified the PoP etc.Sure in this way the original PoP is broken up, but if required the original CSR could be sent along with the modified one. Anyway, the RA needs to be an entity trusted by the CA, so it should not be a problem that it re-builds the CSR.,David On 01.09.21 15:29, Eliot Lear wrote: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._______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
