Transport Layer Security (TLS) Authorization Using KeyNote
draft-keromytis-tls-authz-keynote-07

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: draft-keromytis-tls-authz-keynote-07.txt

The IESG has no problem with the publication of 'Transport Layer Security (TLS) Authorization Using KeyNote' <draft-keromytis-tls-authz-keynote-07.txt> as an Informational RFC.

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17180&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-keromytis-tls-authz-keynote-07.txt


The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Ballot Text

Technical Summary

   This document specifies the use of the KeyNote trust-management
   system as an authorization extension in the Transport Layer
   Security (TLS) Handshake Protocol, according to [AUTHZ].
   Extensions carried in the client and server hello messages
   confirm that both parties support the desired authorization
   data types. Then, if supported by both the client and the
   server, KeyNote credentials are exchanged during the
   supplemental data handshake message.

Working Group Summary

   This document is an independent submission. 

Document Quality

   While there is no existing implementations of the protocol,
   implementation should be straightforward with appropriate TLS
   toolkits.  Future versions of the keynote distribution are
   expected to include any necessary functionality to encode
   and decode the required data structures.

Personnel

   Tim Polk reviewed this document for the IESG.

RFC Editor Note

Proposed response to the RFC Editor
   1. The IESG has concluded that there is no conflict between this
   document and IETF work.

RFC Editor Note