We have struggled with brski-ae to deal with how the pledge can pin a thing from the pledge-agent to prove proximity.
It feels that something like either Delegated STAR could work well. Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10 Failing that, we need to create some kind of JWT, or CWT artifact which the Registrar uses to bless the pledge-agent. We have spoken about gathering the voucher-request artifact from the pledge with the pledge-agent initiating the communication. That is, the pledge is passive for this, and the pledge-agent initiates. Some would call this PUSH, if they are thinking about things from the pledge point of view. But, the pledge-agent has to PULL the voucher-request from the pledge, and then PUSH the voucher-request to the RA... So, I want to suggest that sections 5.1 and 5.2 be renamed. I find the PULL/PUSH terminology confusing. I recognize that the directionality that is implied by the PULL/PUSH is based upon, I thought, whether the RFC8366 voucher is retrieved by the pledge, or provided to the pledge. But, in section 5.1, I think that it's called PULL because the communication with the RA? I guess I am much more interested in the 5.2 interaction! That it could support, for instance, smart-phone + NFC, is very interesting. I believe that it should not be session based (i.e. object security, not TLS or EDHOC). [email protected] wrote: > Title : An ACME Profile for Generating Delegated STAR > Certificates Authors > Abstract: This memo proposes a profile of the ACME protocol that allows > the owner of an identifier (e.g., a domain name) to delegate to a third > party access to a certificate associated with said identifier. A > primary use case is that of a CDN (the third party) terminating TLS > sessions on behalf of a content provider (the owner of a domain name). > The presented mechanism allows the owner of the identifier to retain > control over the delegation and revoke it at any time by cancelling the > associated STAR certificate renewal with the ACME CA. Another key > property of this mechanism is it does not require any modification to > the deployed TLS ecosystem. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
