Re: [TLS] Review of draft-housley-tls-authz-extns-05
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 PROTECTED] 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 PROTECTED]
Sent: 23 May, 2006 19:59
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
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 PROTECTED]
Sent: 23 May, 2006 19:59
To: Eronen Pasi (Nokia-NRC/Helsinki)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
Russ, I concur with Pasi's observations. I don't recall seeing a similar structure in an RFC, where a part is informative, in what is otherwise a standards track document. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
Right. I am proposing the addition of (Informative) after the KeyNote section title. Also, I proposed assigning the KeyNote code point from the specification required set of numbers instead of the set that is associated with standards track documents. Russ At 11:07 AM 5/24/2006, Stephen Kent wrote: Russ, I concur with Pasi's observations. I don't recall seeing a similar structure in an RFC, where a part is informative, in what is otherwise a standards track document. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
On Wednesday, May 24, 2006 02:57:21 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: Right. I am proposing the addition of (Informative) after the KeyNote section title. Also, I proposed assigning the KeyNote code point from the specification required set of numbers instead of the set that is associated with standards track documents. Then I think you should do it in a separate document. Labelling a section as informative does not make it true. The proposed text describes how to implement a feature, and as Pasi points out, it is impossible to produce interoperable implementations of that feature without reading that section. Thus, the section is not informative in nature; it is a normative description of an optional feature. The same applies to the reference. What you really want to do is be able to declare that part of the document to be informational. Thus there would be no downreference, and a year or ten from now when you want to advance the document to draft, it won't be held back due to the lack of independent interoperable implementations of the optional feature. Of course, then you'd end up with the number allocation being a normative downreference from the standards-track portion of the document to the informational portion, but that can be resolved easily enough, since it's really just prepopulating a registry. Unfortunately, our process doesn't have any mechanism for documents which have both a standards-track part and an informational part. While I think what you're trying to do here is reasonable in its intent, I also think that it's likely to create trouble down the road, not because of the normative downref to RFC2704, but because of confusion about the status of the non-standards-track portion of the document. Not to mention the precedent it sets for the next time when someone wants to do the same sort of thing, but with bad intent and undesirable results. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
