Subject: Fwd: TLS authorizations draft

From: Russ Housley <[email-masked]>
Date: Thu, 18 May 2006 10:16:56 -0400

I received this note from Angelos Keromytis regarding the 
draft-housley-tls-authz-extns document.  I plan to accommodate this 
request unless someone raises an objection.

Russ

>Date: Fri, 05 May 2006 19:03:50 -0400
>From: "Angelos D. Keromytis" <[email-masked]>
>To: [email-masked]
>Subject: TLS authorizations draft
>
>Russ,
>Can I talk you into adding support for KeyNote? Basically, in 2.3:
>
>       enum {
>          x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
>          saml_assertion_url(3), keynote_assertion_list(4) (255)
>       } AuthzDataFormat;
>
>and then the text:
>
>    When the keynote_assertion_list value is present, the authorization
>    data is a list of KeyNote assertions that conforms to the profile in
>    RFC 2704 [KEYNOTE].
>
>In Section 3.3, change the enum to be as above, and the first struct to be:
>
>      struct {
>          AuthzDataFormat authz_format;
>          select (AuthzDataFormat) {
>             case x509_attr_cert:         X509AttrCert;
>             case saml_assertion:         SAMLAssertion;
>             case x509_attr_cert_url:     URLandHash;
>             case saml_assertion_url:     URLandHash;
>             case keynote_assertion_list: KeyNoteAssertionList;
>          }
>       } AuthorizationDataEntry;
>
>followed by:
>
>      opaque KeyNoteAssertionList<1..2^16-1>;
>
>A new section:
>
>3.3.4 KeyNote Assertion List
>
>    When KeyNoteAssertion List is used, the field contains an
>    ASCII-encoded list of signed KeyNote assertions, as described
>    in RFC 2704 [KEYNOTE].  The assertions are separated by
>    two '\n' (newline) characters.  A KeyNote assertion is
>    a structure similar to a public key certificate; the main
>    difference is that instead of a binding between a name
>    and a public key, KeyNote assertions bind public keys to
>    authorization rules that are evaluated by the peer when
>    the sender later issues specific requests.
>
>    When making an authorization decision based on a list of
>    KeyNote assertions, proper linkage between the KeyNote
>    assertions and the public key certificate that is transferred
>    in the TLS Certificate message is needed.  Receivers of a
>    a KeyNote assertion list should initialize the ACTION_AUTHORIZER
>    variable to be the sender's public key, which was used to
>    authenticate the TLS exchange.
>
>And the citation:
>
>[KEYNOTE]  "The KeyNote Trust-Management System, Version 2"
>            Matt Blaze, Joan Feigenbaum, John Ioannidis, and Angelos D.
>            Keromytis. Request For Comments (RFC) 2704, September 1999.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 May 2006 16:02:12 -0400

>request unless someone raises an objection.

OK, I'll object :-).

KeyNote has no IETF status, to the best of my knowledge.  It is 
closely aligned with the SDSI/SPKI work for which the IETF created a 
WG, but ultimately rejected as a standards track effort.  So, I find 
it inappropriate to extend this standards track document to include 
support for a technology that, via a tenuous link, never made it to 
standards track status in the IETF.

Steve

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 May 2006 13:24:27 -0700

> standards track status in the IETF.

My inclination is to agree with Steve here.

Is there a substantial deployed base of KeyNote that would motivate
this?

-Ekr