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

["Angelos D. Keromytis" <angelos@xxxxxxxxxxxxxxx>]

Folks, in the interest of keeping it simple, I withdraw the proposed 
text -- I'll just submit a follow up paper using Russ's draft as a template.
-Angelos

Pasi.Eronen@xxxxxxxxx wrote:
> 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