Re: [Lurk] Proposed Lurk Charter

[Василий Долматов <[e-mail]>]

> 13 марта 2016 г., в 23:29, Eric Burger <[e-mail]> написал(а):
> 
> I updated the draft charter with Stephen’s comments.  Not hearing anything for a week tells me either no one has read the proposed charter, everyone thinks it is great, or everyone thinks it is a waste of time and would like their two hours back in BA (BOF scheduled for 2PM on Tuesday, 5 April, in Atlantico C).
> 
> I’m trying something totally new and unknown in the IETF for the first deliverable.  Let me know your opinions.
> 
> This is one of those times when it is OK to simply say ‘OK’ or +1 or ‘Yuck’ or -1.

OK for the start

dol@

> 
> Thanks.
> 
> 
> 
> On Mar 6, 2016, at 9:40 AM, Eric Burger <[e-mail]> wrote:
> 
> It seems we are making progress on the scope discussion on the list, as much about what we want to do as we do not want to do. Given that, and with an eye to BA, let us tear apart the following charter. It would be fantastic to have some thought out text to show the broader IETF community in April.
> 
> Note the charter references at least two different proposals for achieving the goals. I see this as a good thing: it means we are not researching science fiction (a hallmark of failed IETF work groups) and rather are doing engineering (a hallmark of successful IETF work groups). It also says we are not rubber-stamping some vendor’s proprietary protocol, which just tastes bad.
> 
> Comments please!
> 
> 
> 
> 
> Description of Working Group:
> HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. Currently most trust models assume the HTTP server owns the private keys, and that the server is responsible for both the hosted content and for the network delivery. Although these assumptions were somewhat true in the past, today, the deployment of services on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application - like a web browser - expects to authenticate a content provider but is actually authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content.
> 
> This work group will provide a solution to the  "offload TLS without giving the CDN my private key" use-case. The work group may also provide support for DTLS in anticipation of future secure protocols.
> 
> This work group will not address the Email and STIR use cases of an enterprise or individual delegating their private key to a service provider for signing messages on their behalf.
> 
> Related Work:
> OASIS developed the Key Management Interoperability Protocol (KMIP) <http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html> as well as PCKS #11, Cryptographic Token Interface <http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html>.
> 
> 
> Goals and Milestones:
> Oct 2016	  Requirements and Use Cases Document stable with consensus to content
> Feb 2017   HTTPS delegated protocol Document to IESG
> Jun 2017   DTLS delegated protocol Document to IESG
> Oct 2016	  Requirements and Use Cases Document to IESG
> 
> 
> 
> Reading list
> • ​https://tools.ietf.org/html/draft-mglt-lurk-tls-requirements
> • ​https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases
> • ​https://tools.ietf.org/html/draft-cairns-tls-session-key-interface
> • ​https://tools.ietf.org/html/draft-hallambaker-mesh-architecture
> 
> _______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk