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@xxxxxxxxxxxx] > Sent: 23 May, 2006 19:59 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: kent@xxxxxxx; mark@xxxxxxxxxxxxxxxxxxxx; > angelos@xxxxxxxxxxxxxxx; ekr@xxxxxxxxxxxxxxxxxxxx; ietf@xxxxxxxx > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf