Hi, all, While working on the STAR delegation protocol we realised that the "STAR" in "ACME STAR Delegation" is not a strict precondition to build a delegation mechanism, and that we could quite easily relax the assumption and have a more general ACME-based delegation that can work with both STAR and traditional certs.
In order to do that, from a protocol mechanics standpoint, we'd just need to add one "allow-certificate-get" attribute to the set of top-level Order attributes, and one to the Directory's meta, with same exact semantics as those currently defined in the "auto-renewal" namespace. >From an interface perspective, the only difference between non-STAR and STAR delegation is that the former would allow the delegate to revoke the cert using the cert's private key, whereas STAR certs don't have access to the revocation interface -- that was originally conceived to give tighter control to the delegator. However, in hindsight it doesn't seem like this would imply an increase in attack surface, while the gain we'd get from the generalisation of the mechanism is quite noticeable, we reckon. Obviously we want to validate this scope change with the group before proceeding. Cheers! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
