Russ,
I don't think this is good use of "informative" text. Other
standards bodies often mark some sections of a specification
as informative, but those sections are text that is helpful
for understanding the specification, but is not required to
implement it.
The KeyNote section is clearly part of the technical specification,
and required reading to get interoperable implementations of this
feature.
Also, my reading of RFC2026 is that the "Proposed Standard" status
applies to whole documents, and I found nothing there that would
support approving only some specific sections of a document as
Proposed Standard, while leaving other sections as Informational
or Experimental....
Best regards,
Pasi
-----Original Message-----
From: ext Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com]
Sent: 23 May, 2006 19:59
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: kent(_at_)bbn(_dot_)com; mark(_at_)redphonesecurity(_dot_)com;
angelos(_at_)cs(_dot_)columbia(_dot_)edu;
ekr(_at_)networkresonance(_dot_)com; ietf(_at_)ietf(_dot_)org
Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05
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(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf