Re: [Lurk] Fwd: New Version Notification for draft-sheffer-lurk-cert-delegation-00.txt

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

On 25/05/2016 14:46, "Yaron Sheffer" <[e-mail]> wrote:
>>Hi Yaron,
>>
>> On 12/05/2016 22:10, "Lurk on behalf of EXT Yaron Sheffer"
>> <[e-mail] on behalf of [e-mail]> wrote:
>>> To solve the CDN-shouldn't-get-my-private-key scenario, I propose an
>>> almost trivial REST API, where the CDN contacts the content owner once
>>>a
>>> day and obtains a 3 day credential (private key plus short-term cert).
>>>
>>> Comments are welcome!
>>
>> Thanks very much for the draft.
>>
>> Your proposal has a few good properties:
>> - It's very simple, with minimal impact on existing implementations and
>> deployments;
>> - It scales very well, because it drastically reduces the number of
>>calls
>> to the LURK box (somewhere about 10 orders of magnitude less than the
>> other proposals), and because it removes the need for keeping the LURK
>> box near the edge - and thus deploying more boxes as the CDN footprint
>> grows -- if the application cares about time-to-first-byte, as it
>>usually
>> does;
>> - It makes the CDN less dependent on the availability of the LURK box;
>> - Lastly, it seems to provide the right ecosystem for solving the well
>> known revocation issues ([1], [2]) -- very similarly to a proposal from
>> Topalovic et al. [3].
>>
>> The only "minus" point is that the CDN still holds the content
>>provider's
>> private key.  In fact, in your proposal, the "Remote Keys" in the LURK
>> acronym aren't remote at all :-)
>>
>> Cheers, t
>>
>> [1] https://www.imperialviolet.org/2011/03/18/revocation.html
>> [2] https://www.imperialviolet.org/2014/04/29/revocationagain.html
>> [3] http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf
>>
>
>We could always rename the group LUCK - C for "cached"...
>
>Or else we could decide that we have another use case for remote signing
>boxes, one that's better than CDNs.

Just to clarify: what are you proposing above in relationship to the
proposed charter 
(https://www.ietf.org/mail-archive/web/lurk/current/msg00080.html) is:
(a) To extend it to include the "ephemeral keys" use-case/solution
alongside the TLS interface?
(b) To change LURK into LUCK and get rid of the TLS interface?


Cheers, t