> On Jul 20, 2016, at 2:51 AM, Yaron Sheffer <[email protected]> wrote: > > Option 2: Certificate Delegation > > This option moves more of the responsibility to the ACME server. > > 1. Domain owner contacts the ACME server and obtains a "delegation > ticket" which is specific to the TLS server. The ticket is good for a > long period, e.g. 1 year. > > 2. TLS server regularly contacts the ACME server, proves ownership of > the delegation ticket, and receives a short-term certificate. > > If something bad happens, the domain owner contacts the ACME server and > revokes the delegation ticket.
I just wanted to check some intuition out here. Would an [RFC5755] Attribute Certificate work effectively as a “delegation ticket”, within the meaning of Option 2 that you’re proposing? I know people want to hate on ACs, and they aren’t widely deployed. But maybe that would be the right kind of pre-existing protocol element for this sort of thing. AC has a Holder field; presumably the holder field would identify the the TLS server, the main certificate, or both. Proving ownership of the delegation ticket, is just transmitting the AC. Possession is sufficient. ACs can be revoked, as they use the same machinery as regular certificates, via CRLs (and OCSP). Again, component reuse. ACs are signed, so they are verifiable as coming from the ACME server. If you don’t like full public-key signatures you can generate a “signature” (with a new/appropriate OID) based on some shared secret. ACs have dates. So that part is satisfied. You can still hate on ACs and invent some different thing; you could also use SAML or whatever. Just checking the intuition, and thinking about reusing existing componentry. Where do ACs match up, and where do they break down? Regards, Sean _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
