Re: [TLS] Review of draft-housley-tls-authz-extns-05

[Russ Housley <housley at vigilsec.com>]

Pasi:

Steve Kent and Eric Rescorla made similar comments to your third point:

> 3) The document is last called for Proposed Standard, but contains
>    a normative reference to Informational RFC (RFC 2704). I'd
>    suggest removing the KeyNote stuff from this document (if someone
>    really wants to do KeyNote, it can be a separate document).

I would like to propose a way forward on this point.  It involves 
three changes.

First, I suggest a different code point assignment:

      enum {
         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
         saml_assertion_url(3), keynote_assertion_list(64), (255)
      } AuthzDataFormat;

Second, I propose the following text:

   3.3.4. KeyNote Assertion List (Informative)

   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 KeyNote assertion list should
   initialize the ACTION_AUTHORIZER variable to be the sender's public
   key, which was used to authenticate the TLS exchange.

Third, I suggest making the [KEYNOTE] reference informational.

What do you think?  Is this a reasonable compromise?

Russ 


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf