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

From: "Angelos D. Keromytis" <[email-masked]>
Date: Wed, 24 May 2006 14:00:22 -0400

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

[email-masked] 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:[email-masked]] 
>> Sent: 23 May, 2006 19:59
>> To: Eronen Pasi (Nokia-NRC/Helsinki)
>> Cc: [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]
>> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Wed, 24 May 2006 14:00:22 -0400