Thanks, I'll whack that in. I assume the WG don't want (or don't care about) external review? If there were some other SDO (e.g. IEEE, W3C etc) who you think might need to know then external review would be correct, but I don't think that applies. Correct me if that's wrong,
Cheers, S. On 20/05/14 15:49, Olafur Gudmundsson wrote: > > Stephen, > below is our draft charter please take it to the IESG. > > Olafur & Warren > > Current Status: Active > > Chairs: > Warren Kumari > Olafur Gudmundsson > > Security Area Advisor: > Stephen Farrell > > Description of Working Group: > > Objective: > > The DANE WG will process documents that describe how to > incorporate DANE and DANE-like functionality in protocols, and > mechanisms to facilitate adoption of this functionality. The DANE > working group will also assist other working groups with adding > DANE functionality to their work. In addition the working group > will monitor and provide guidance to operators and tool developers. > When work on currently chartered documents is complete the WG > may re-charter if sufficiently pressing new work is identified. > DANE is not intended to be a long-lived catch-all WG > for all PKI in DNS issues and so will generally not adopt new > work items without re-chartering. > > Problem Statement: > > The DANE working group has developed a framework for securely > retrieving keying information from the DNS [RFC6698]. This > framework allows secure storing and looking up server public key > information in the DNS. This provides a binding between a domain > name providing a particular service and the key that can be used > to establish encrypted connection to that service. > > By requiring DNSSEC protection for the lookup of the public key > information, DANE leverages the integrity protection provided by > DNSSEC to enable secure discovery of keying information. Operators > wanting to take advantage of DANE for their services must turn on > DNSSEC signing on the zones used in finding the services. Using > DNS this way, bindings of keys to domains are asserted by the entities > that > operate the DNS for that domain, not by external entities. > > The DANE mechanisms provide flexibility in how the keying > information is presented. DANE supports both Certificates and raw > keys, further more Certificates and raw keys can be either the full > key or a hash of the key. > The group will work on documenting the different approaches to use > DANE keying, and the security implication of each. In addition > the WG may develop a framework(s) to facilitate the lookup "client" DANE > records for authorization/authentication purposes. > > The group may also create documents that describe how protocol > entities can discover and validate these bindings in the execution > of specific applications. This work would be done in coordination > with the IETF Working Groups responsible for the protocols. > > The group may in addition encourage interoperability testing and document > the results of such testing. > > Goals and Milestones: > DONE - First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > DONE - Protocol for using DNS to associate domain names with keys for TLS > and DTLS to IESG > Jun 2014 - Advance DANE SRV document to IESG > Jun 2014 - Advance DANE SMTP document to IESG > Aug 2014 - Advance DANE SMIME document to IESG > Aug 2014 - Advance DANE OPENPGP document to IESG > Sep 2014 - Advance DANE operational guidance/errata document to IESG > Jan 2015 - Advance DANE security model document to IESG. > May 2015 - Advance DANE IPSEC document to IESG > ??? 2015 - Advance DANE reverse binding (server to client) document to IESG. > Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard > Nov 2015 - Recharter or close down > > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
