> On Jul 22, 2016, at 4:02 AM, Yaron Sheffer <[email protected]> wrote: > > On 22/07/16 12:56, Richard Barnes wrote: >> >> >> On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 21/07/16 12:36, Sean Leonard wrote: >> >> >> On Jul 20, 2016, at 2:51 AM, Yaron Sheffer >> <[email protected] <mailto:[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? >> > [snip] >> >> 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 >> > > Hi Richard, > > It's kind of early for this level of detail, but don't you think a simple JWT > (https://tools.ietf.org/html/rfc7519) signed by the ACME server is sufficient > here?
Uh oh, bike-shedding on specs. ;-) There are at least four delegation ticket technologies floating around IETF to my knowledge: attribute certificate JWT OAuth Kerberos ...and I am sure there are others. My overall point is that for Option 2, there was a discussion point that Option 2 would be too complicated to implement: “Option 2 is clearly more complicated to specify and to implement.” Well it has to involve more technology, but if you use an off-the-shelf piece of tech that works, then we don’t need to invent a fifth (or nth) ticket delegation technology that happens to be specific to ACME. Sean PS Re: attribute certificates, there is a noRevAvail extension, which allows an issuer to state explicitly that there is no revocation information, so don’t bother checking. This means it’s an option that some issuers can have revocation info and some won’t. Some ppl may be bothered by too many options; others will like the optionality. I don’t think the other delegation ticket technologies have such optionality, as they come to mind. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
