On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer <[email protected]> wrote:
> On 21/07/16 12:36, Sean Leonard wrote: > >> >> 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 >> >> > Hi Sean, > > Attribute certs would have been a wonderful fit here, but to the best of > my knowledge, they've never been (widely) implemented. They have been a > great idea with no practical use since 2002. And if we propose to use them > here, it's a sure way to kill this option outright. > > More specifically, when you say "ACs can be revoked" this is somewhat > ironic. The generally accepted wisdom is that certificates cannot be > reliably revoked today, and in fact this is the main reason why we need > short-term certificates for the CDN use case! > Yeah, I sent the following to Sean yesterday and forgot to CC the list: """ I mean, technically yes, ACs would work here, in the sense that a tank will get you to the office :) I think the more likely candidate is OAuth, since (a) ACME is based on HTTP, and (b) OAuth is built for delegating authorization. """ --Richard > > Thanks, > Yaron > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
