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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf