Skip to main content

Transport Layer Security (TLS) Authorization Extensions
RFC 5878

Revision differences

Document history

Date Rev. By Action
2020-01-21
09 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
09 (System) Notify list changed from housley@vigilsec.com, mark@redphonesecurity.com to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2010-05-06
09 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2010-05-06
09 Amy Vezza [Note]: 'RFC 5878' added by Amy Vezza
2010-05-05
09 (System) RFC published
2009-10-16
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-10-16
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-10-16
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-10-16
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-10-15
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-10-15
09 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2009-10-15
09 Cindy Morgan IESG state changed to Approved-announcement sent
2009-10-15
09 Cindy Morgan IESG has approved the document
2009-10-15
09 Cindy Morgan Closed "Approve" ballot
2009-10-14
09 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Undefined by Pasi Eronen
2009-10-14
09 Pasi Eronen [Ballot comment]
2009-10-14
09 Pasi Eronen [Ballot discuss]
2009-10-14
09 Pasi Eronen [Ballot Position Update] Position for Pasi Eronen has been changed to Undefined from Discuss by Pasi Eronen
2009-10-14
09 Alexey Melnikov
[Ballot comment]
5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of …
[Ballot comment]
5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)
2009-10-14
09 Alexey Melnikov [Ballot discuss]
2009-10-14
09 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2009-10-14
09 (System) New version available: draft-housley-tls-authz-extns-09.txt
2009-09-21
09 Pasi Eronen
[Ballot comment]
The abstract simply talks about "authorization information"
without giving much clue to the reader what the word means in this
context. Saying e.g. …
[Ballot comment]
The abstract simply talks about "authorization information"
without giving much clue to the reader what the word means in this
context. Saying e.g. "...authorization information, such as Attribute
Certificates or SAML Assertions, ..." would make it more
understandable.
2009-09-21
09 Pasi Eronen
[Ballot discuss]
Updated discuss for version -08:

1) The latest version of the document changes the definition of the
"access_denied" alert (from the TLS main …
[Ballot discuss]
Updated discuss for version -08:

1) The latest version of the document changes the definition of the
"access_denied" alert (from the TLS main specification) to allow it be
non-fatal. I don't think this is a good idea. The definition in RFC
5246
is not about certificate processing, but authorization/access
control processing -- so failed authorization is already covered
there. If a new informative warning message is really needed (I don't
think it is), it should use a different number.

2) Section 2.3 says mismatched hash should result in bad_certificate
alert. Why not "bad_certificate_hash_value"?

3) Despite all the new text about alerts, the document doesn't
seem to tell what to do if downloading the URL
fails. ("certificate_unobtainable" alert -- which can be fatal or
warning -- is one obvious option)

4) Section 4 should explicitly say that all the alerts discussed here
are always fatal (except "certificate_unobtainable").

In addition, there's couple of places that probably need some
clarifications and/or minor fixes:

- Section 3.3.3 needs some references about the MIME types
(draft-ietf-pkix-attr-cert-mime-type and perhaps the IANA page or
some OASIS spec for samlassertion).

- Section 6: "For more information, see Section 6.3 of [TLS1.2]."
Should be "... Section 6.3 of [RFC4366]".

- Some of the references need updating: [SHA1] and [SHA2] have been
superseded by FIPS 180-3.

- Section 3.2, "Handshake.length = 15" should be 17 to match
the hex dump.
2009-09-17
09 Alexey Melnikov
[Ballot comment]
RFC 2279 was obsoleted by RFC 3629.


5. Security Considerations

  A TLS server can support more than one application, and each …
[Ballot comment]
RFC 2279 was obsoleted by RFC 3629.


5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)
2009-09-17
09 Alexey Melnikov
[Ballot discuss]
Updated as per draft-housley-tls-authz-extns-08.txt:

In section 2.3:

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the …
[Ballot discuss]
Updated as per draft-housley-tls-authz-extns-08.txt:

In section 2.3:

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the http scheme
  [UPGRADE].

If you meant "http", then the reference is incorrect. It must be
RFC 2616.
If you meant "https", then the reference should be to RFC 2818.
2009-09-17
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-09-17
08 (System) New version available: draft-housley-tls-authz-extns-08.txt
2009-08-14
09 (System) Removed from agenda for telechat - 2009-08-13
2009-08-13
09 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead::External Party by Cindy Morgan
2009-08-13
09 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-08-12
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-08-11
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-08-10
09 Pasi Eronen
[Ballot comment]
The abstract and introduction simply talk about "authorization
information" without giving much clue to the reader what the word
means in this context. …
[Ballot comment]
The abstract and introduction simply talk about "authorization
information" without giving much clue to the reader what the word
means in this context. Saying e.g. "...authorization information,
such as Attribute Certificates or SAML Assertions, ..." would
make it more understandable.

In earlier IETF Last Call comments, I suggested increasing the
maximum lengths to more than 64K (especially SAML assertions
can be large, and there could be more than one of them). However,
investigating more, it seems using Supplemental Data message
limits us to 64K anyway. So changing the length fields in
this document wouldn't help.
2009-08-10
09 Pasi Eronen
[Ballot discuss]
I have reviewed draft-housley-tls-authz-extns-07, and have couple of
questions/concerns that I'd like to discuss before recommending
approval of the document. And no, …
[Ballot discuss]
I have reviewed draft-housley-tls-authz-extns-07, and have couple of
questions/concerns that I'd like to discuss before recommending
approval of the document. And no, none of these are related
to the process :-)

1) The document is not very clear on how these extensions apply to TLS
session resumption. Probably the intent is that if the server
decides to resume a session, these extensions (and supplemental data
messages etc.) are not used (and the authorization information comes
from the session cache). But Section 2 and 1.2 should clearly say so.

2) The document never actually says what the implementation should do
if the hash of the downloaded URL doesn't match the hash in the
message, or if downloading the URL fails. (Failing with some TLS alert
message or continuing without the authorization information would be
the obvious choices.)

3) The document should use the existing TLS HashAlgorithm IANA
registry instead of creating a new HashType registry.

4) Section 3.3.2 says the field contains "an XML-encoded "
element, but is not clear how the recipient determines the character
encoding for parsing the XML. RFC 3470 discusses several possibilities
-- the simplest of which would be just saying "MUST be UTF-8" -- but
if recipients are expected to support something more complex (BOMs,
XML declarations, etc.) the document should say so.

In addition, there's couple of places that probably need some
clarifications and/or minor fixes:

- The document says it applies to TLS 1.0 and TLS 1.1, but I'd expect
it to be version independent (applies to TLS 1.2, too -- and possibly
future versions, too).

- The hash+URL formats have a major security consideration that's not
mentioned in the document: an attacker can get the other end to fetch
any URL (which doesn't necessarily point to a certificate, and might
not be reachable by the attacker). (A one-sentence summary plus a
pointer to RFC 4366 Section 6.3 would probably be sufficient, though.)

- Section 3.2 should be clearer about what the SupplementalDataEntry
structure contains (currently, it's ambiguous whether there are one or
two 16-bit length fields after "supp_data_type" ).

- Section 2 duplicates several paragraphs worth of text from RFC
3546
. That RFC has since been obsoleted, and this text has been
slightly rephrased and clarified -- but I think repeating general
description of TLS extensions (e.g. if there are multiple extensions,
they can be in any order) is not necessary here, and could be just
removed. Especially since the text uses 2119 keywords, it's not very
obvious that the "MUSTs" here are not actually new requirements.

- The document should not "Update" RFC 4346.

- The hash+URL cases probably need some additional guidance about use
of HTTP (redirects, caching, etc.). Probably a pointer to RFC 4366's
text would be sufficient for everything else than the MIME types.

- For the MIME types, it seems "application/samlassertion+xml" already
exists, and should be mentioned here. But what should be used for
attribute certificates?  Is "application/pkix-cert" only for X.509v3
PKCs?

- Some of the references need updating: [IANA] has been obsoleted by
RFC 5226 (and some of the IANA policy names changed, too).  [PKIX1]
has been obsoleted by RFC 5280.  [TLSEXT] has been obsoleted (for the
purposes of this document) by RFC 5246.  [TLSSUPP] is now RFC 4680.
[SHA1] and [SHA2] have been superseded by FIPS 180-3.
2009-08-10
09 Pasi Eronen [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen
2009-08-08
09 Alexey Melnikov
[Ballot comment]
3.3.3. URL and Hash

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
  as …
[Ballot comment]
3.3.3. URL and Hash

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
  as one-way hash functions.  Other one-way hash functions may also be
  supported.  Additional one-way hash functions can be registered in
  the future using the procedures in section 3.

I think this should point to section 4 (IANA Considerations).


5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)
2009-08-08
09 Alexey Melnikov
[Ballot discuss]
Updated after some clarifying discussions with authors:

3.3.3. URL and Hash

[...]

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support …
[Ballot discuss]
Updated after some clarifying discussions with authors:

3.3.3. URL and Hash

[...]

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the http scheme.
  Other schemes may also be supported; however, to avoid circular
  dependencies, supported schemes SHOULD NOT themselves make use of
  TLS, such as the https scheme.

I believe this require a normative reference to RFC 2616, which
defines HTTP URIs.


4. IANA Considerations

  This document establishes a new registry, to be maintained by IANA,
  for TLS Authorization Data Formats.  The first four entries in the
  registry are x509_attr_cert(0), saml_assertion(1),
  x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
  Data Format identifiers with values in the inclusive range 0-63
  (decimal) are assigned via RFC 2434 [IANA] Standards Action.

I understand that this is probably pedantic, but this document is targeted
for Experimental, yet it tries to assign a value in the section that
requires Standards Action. Besides, why prevent registrations of types of authorization data to Standard Track documents?
So, should this requirement be relaxed?


The same issue with Hash Types.

  Values
  from the inclusive range 64-223 (decimal) are assigned via RFC 2434
  Specification Required.  Values from the inclusive range 224-255
  (decimal) are reserved for RFC 2434 Private Use.
2009-08-04
09 Alexey Melnikov
[Ballot comment]
3.3.3. URL and Hash

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
  as …
[Ballot comment]
3.3.3. URL and Hash

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
  as one-way hash functions.  Other one-way hash functions may also be
  supported.  Additional one-way hash functions can be registered in
  the future using the procedures in section 3.

I think this should point to section 4 (IANA Considerations).


5. Security Considerations

  A TLS server can support more than one application, and each
  application may include several features, each of which requires
  separate authorization checks.  This is the reason that more than one
  piece of authorization information can be provided.

  A TLS server that requires different authorization information for
  different applications or different application features may find
  that a client has provided sufficient authorization information to
  grant access to a subset of these offerings.  In this situation the
  TLS Handshake protocol will complete successfully; however, the
  server must ensure that the client will only be able to use the
  appropriate applications and application features.  That is, the TLS
  server must deny access to the applications and application features
  for which authorization has not been confirmed.

s/must/MUST ? (twice)
2009-08-04
09 Alexey Melnikov
[Ballot discuss]
2.2. The server_authz Extension Type

  Clients MUST include the server_authz extension type in the extended
  client hello message to indicate their …
[Ballot discuss]
2.2. The server_authz Extension Type

  Clients MUST include the server_authz extension type in the extended
  client hello message to indicate their desire to receive
  authorization data from the server.

This looks like cut & paste of the first paragraph in section 2.1.
Should "client" be changed to "server" everywhere (and vice versa)?


3.3.3. URL and Hash

[...]

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the http scheme.
  Other schemes may also be supported; however, to avoid circular
  dependencies, supported schemes SHOULD NOT themselves make use of
  TLS, such as the https scheme.

I believe this require a normative reference to RFC 2616, which
defines HTTP URIs.


4. IANA Considerations

  This document establishes a new registry, to be maintained by IANA,
  for TLS Authorization Data Formats.  The first four entries in the
  registry are x509_attr_cert(0), saml_assertion(1),
  x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
  Data Format identifiers with values in the inclusive range 0-63
  (decimal) are assigned via RFC 2434 [IANA] Standards Action.

I understand that this is probably pedantic, but this document is targeted
for Experimental, yet it tries to assign a value in the section that
requires Standards Action. Should this requirement be relaxed?

The same issue with Hash Types.

  Values
  from the inclusive range 64-223 (decimal) are assigned via RFC 2434
  Specification Required.  Values from the inclusive range 224-255
  (decimal) are reserved for RFC 2434 Private Use.
2009-08-04
09 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-08-02
09 Adrian Farrel [Ballot Position Update] New position, Abstain, has been recorded by Adrian Farrel
2009-08-02
09 Adrian Farrel
[Ballot comment]
There seems to be a little history associated with this draft. Rather thn read up on the details I am going to Abstain. …
[Ballot comment]
There seems to be a little history associated with this draft. Rather thn read up on the details I am going to Abstain. The draft seems to have enough votes to go through and I see nothing specific in the draft to object to. I am going to trust the rest of the IESG to have derived the right conclusions from history.

I am a little confused by the flopping of the status of the I-D. It seems that the most recent last call was on Standards Track, yet the I-D has now moved to Experimental (again). I gues that, since a last call was also held on that track, we don't have a problem with that.
2009-08-02
09 Tim Polk
Since the TLS working group has had no drafts and no discussions regarding authorization, I have determined that moving this document forward does not constitute …
Since the TLS working group has had no drafts and no discussions regarding authorization, I have determined that moving this document forward does not constitute an end around, and will ask the IESG to consider approving this for publication as an experimental RFC.
2009-08-02
09 Tim Polk Placed on agenda for telechat - 2009-08-13 by Tim Polk
2009-04-15
09 Tim Polk State Changes to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Tim Polk
2009-04-15
09 Tim Polk Waiting for TLS working group to decide whether they wish to take on work in this space.
2009-03-11
09 David Ward [Ballot Position Update] New position, Abstain, has been recorded by David Ward
2009-03-11
09 Tim Polk Removed from agenda for telechat - 2009-03-12 by Tim Polk
2009-03-06
09 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2009-03-06
09 Tim Polk Ballot has been issued by Tim Polk
2009-03-06
09 Tim Polk Created "Approve" ballot
2009-03-06
09 Tim Polk Placed on agenda for telechat - 2009-03-12 by Tim Polk
2009-03-06
09 Tim Polk Intended Status has been changed to Experimental from Proposed Standard
2009-02-11
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-01-15
09 Amanda Baber
IANA Last Call comments:

ACTION 1:

Upon approval of this document, IANA will register the following
ExtensionType Values at
http://www.iana.org/assignments/tls-extensiontype-values

Value Extension name Reference
----- …
IANA Last Call comments:

ACTION 1:

Upon approval of this document, IANA will register the following
ExtensionType Values at
http://www.iana.org/assignments/tls-extensiontype-values

Value Extension name Reference
----- -------------- --------------------------------
7 client_authz [RFC-housley-tls-authz-extns-07.txt]
8 server_authz [RFC-housley-tls-authz-extns-07.txt]

Values 7 and 8 are currently reserved for use by this document.


ACTION 2:

Upon approval of this document, IANA will register the following
TLS SupplementalDataType at
http://www.iana.org/assignments/tls-parameters:

Value Description Reference
----- ----------- ---------
TBD authz_data [RFC-housley-tls-authz-extns-07.txt]


ACTION 3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/tls-parameters:

Registry Name: TLS Authorization Data Formats
Range Registration Procedures
--------- -----------------------
0-63 Standards Action
64-223 Specification Required

Value Description Reference
------- ------------------------ ---------
0 x509_attr_cert [RFC-housley-tls-authz-extns-07.txt]
1 saml_assertion [RFC-housley-tls-authz-extns-07.txt]
2 x509_attr_cert_url [RFC-housley-tls-authz-extns-07.txt]
3 saml_assertion_url [RFC-housley-tls-authz-extns-07.txt]
4-223 Unassigned
224-255 Reserved for Private Use [RFC-housley-tls-authz-extns-07.txt]


ACTION 4:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/tls-parameters:

Registry Name: TLS Hash Types
Range Registration Procedures
--------- -----------------------
0-158 Standards Action
159-223 Specification Required

Value Description Reference
------- ------------------------ ---------
0 sha1 [RFC-housley-tls-authz-extns-07.txt]
1 sha256 [RFC-housley-tls-authz-extns-07.txt]
2-223 Unassigned
224-255 Reserved for Private Use [RFC-housley-tls-authz-extns-07.txt]


We understand the above to to be the only IANA Actions for this
document.
2009-01-14
09 Amy Vezza Last call sent
2009-01-14
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-01-14
09 Tim Polk Intended Status has been changed to Proposed Standard from Experimental
2009-01-14
09 Tim Polk Last Call was requested by Tim Polk
2009-01-14
09 Tim Polk State Changes to Last Call Requested from Waiting for AD Go-Ahead by Tim Polk
2008-11-19
(System) Posted related IPR disclosure: RedPhone Security's Statement about IPR related to draft-housley-tls-authz-extns-07
2008-03-19
(System) Posted related IPR disclosure: RedPhone Security's Statement about IPR related to draft-housley-tls-authz-extns-07
2008-01-07
(System) Posted related IPR disclosure: RedPhone Security's Statement about IPR related to draft-housley-tls-authz-extns-07
2007-10-23
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-09-26
09 Amanda Baber
IANA Last Call comments:

Upon approval of this document, IANA will register the following:
Two new TLS extensions in
http://www.iana.org/assignments/tls-extensiontype-values

client_authz
server_authz

Values 7 and …
IANA Last Call comments:

Upon approval of this document, IANA will register the following:
Two new TLS extensions in
http://www.iana.org/assignments/tls-extensiontype-values

client_authz
server_authz

Values 7 and 8 are currently reserved for use by this document.

One TLS supplemental data type in
http://www.iana.org/assignments/tls-parameters:

authz_data

The IANA will also create the following new registries:

TLS Authorization Data Formats. The initial entries in the TLS
Authorization Data Formats registry will be:

0 x509_attr_cert
1 saml_assertion
2 x509_attr_cert_url
3 saml_assertion_url

TLS Hash Types. The initial entries in the TLS Hash Types registry
will be:

0 sha1
1 sha256

We understand the above to to be the only IANA Actions for this
document.
2007-09-20
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-09-20
09 Tim Polk Last Call was requested by Tim Polk
2007-09-20
09 Tim Polk State Changes to Last Call Requested from AD Evaluation by Tim Polk
2007-09-20
09 Tim Polk State Changes to AD Evaluation from Publication Requested by Tim Polk
2007-09-10
09 Tim Polk State Changes to Publication Requested from Dead by Tim Polk
2007-09-10
09 Tim Polk Intended Status has been changed to Experimental from Proposed Standard
2007-09-10
09 Tim Polk Responsible AD has been changed to Tim Polk from Sam Hartman
2007-09-10
09 (System) This document has been resurrected.
2007-09-10
09 (System) This document has been resurrected.
2007-09-10
09 Tim Polk I-D Resurrection was requested by Tim Polk
2007-06-12
09 (System) Document has expired
2007-06-11
09 Sam Hartman State Changes to Dead from Waiting for AD Go-Ahead by Sam Hartman
2007-06-11
09 Sam Hartman



Folks, after the various IPR disclosures were filed on
draft-housley-tls-authz-extns, I asked for a second IETF last call to
see if we had consensus …



Folks, after the various IPR disclosures were filed on
draft-housley-tls-authz-extns, I asked for a second IETF last call to
see if we had consensus to publish this document on the standards
track given the IPR claims against it.

That last call did not show the consensus I was looking for.  So, we
agreed we were going to send mail to the TLS working group and ask
them for their comments on publishing the draft.  We hoped that we'd
see a consensus there.  The chairs did ask for comments; see
http://www1.ietf.org/mail-archive/web/tls/current/msg01688.html .

Comments were provided, but there was not a consensus in favor of
publication on the standards track either there or on the ietf list.

I think there is a rough consensus against publication on the
standards track.  However it is quite clear that there is not a rough
consensus in favor of publication on the standards track which would
be required to do so.

So, I am withdrawing my sponsorship of the draft and as far as the
IETF process is concerned this draft is no longer under consideration
for publication.

One option that several people suggested is publication as an
informational spec.  I personally do not choose to sponsor this
document for informational or experimental.  often, it seems that we
use informational as a way to publish things we cannot build a strong
consensus behind.  I think that process is generally problematic and
would like to avoid it in this instance.  Other ADs may consider
sponsoring this document as an informational document; I would ask
them to carefully consider whether that is the best use of the time
they have to offer the IETF community.  My conclusion is that for me
personally, it is not.

Publishing this document via the rfc editor independent submissions
track is basically not an option because the IANA assignments require
IETF consensus or standards action.


That leaves the authors with several options:

* Work with people to build consensus and try again later.  Possibly
  working on discovering prior art or trying to revise the licensing
  terms.  There should be a much higher bar for starting the process a
  second time, but perhaps that bar can be met.



* Work on an alternative that does not have the IPR constraints.

* Work on finding another AD to sponsor the document.  I will not do
  so, and I'd advise my fellow ADs to think for a long time before
  taking on this draft, but I would not block another AD sponsoring
  the draft.

* Rewrite this document as a sketch of what might be done rather than a protocol and go through the independent submissions track.

* Drop the proposal.



I'm sad that we have come to this point.  I think this technology has
significant value and wish we'd found a way to publish it.  However we
follow a consensus process for many valuable reasons and it is clear
that the necessary consensus is not present in this case.
Sam Hartman
Security Area Director
2007-03-05
(System) Posted related IPR disclosure: Stephen Farrell's statement about possible IPR claimed in draft-housley-tls-authz-extns-07.txt belonging to Siemens
2007-02-27
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-02-27
09 Amy Vezza State Changes to In Last Call from Waiting for AD Go-Ahead by Amy Vezza
2007-02-27
(System) Posted related IPR disclosure: Eric Rescorla's statement about possible IPR claimed in draft-housley-tls-authz-extns-07.txt belonging to IBM Corporation
2007-02-26
09 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-02-26
09 Amy Vezza State Changes to In Last Call from RFC Ed Queue by Amy Vezza
2006-11-08
09 (System) Request for Early review by SECDIR is assigned to Juergen Quittek
2006-11-08
09 (System) Request for Early review by SECDIR is assigned to Juergen Quittek
2006-10-26
09 (System) IANA Action state changed to Waiting on RFC Editor from RFC-Ed-Ack
2006-10-25
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2006-10-02
09 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2006-09-28
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-09-28
09 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2006-06-30
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-06-27
09 Amy Vezza IESG state changed to Approved-announcement sent
2006-06-27
09 Amy Vezza IESG has approved the document
2006-06-27
09 Amy Vezza Closed "Approve" ballot
2006-06-22
09 Sam Hartman State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Sam Hartman
2006-06-09
09 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2006-06-08
09 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2006-06-08
09 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-06-08
09 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-06-08
09 Russ Housley [Ballot Position Update] New position, Recuse, has been recorded for Russ Housley by Russ Housley
2006-06-08
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-06-08
09 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson by Jon Peterson
2006-06-07
09 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-06-07
09 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-06-07
09 Dan Romascanu
[Ballot comment]
This comment is related to the IESG discussion about references style. This document seems to propose a third style in what concerns references …
[Ballot comment]
This comment is related to the IESG discussion about references style. This document seems to propose a third style in what concerns references to RFC documents. for example a reference to RFC 2119 is not labeled as [RFC2119] or [3], but as [STDWORDS]. Moreover, the RFC numbers are not sorted, as it seems to be the current practices within the Normative References or Informative References sections. I know that we avoid having too many rules, and that we do not have consensus about a recommended style for references, still I find this confusing.
2006-06-07
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-06-07
09 Ted Hardie
[Ballot discuss]
In Section 3.3.3, the document says:

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the http scheme. …
[Ballot discuss]
In Section 3.3.3, the document says:

  Implementations that support either x509_attr_cert_url or
  saml_assertion_url MUST support URLs that employ the http scheme.
  Other schemes may also be supported; however, to avoid circular
  dependencies, supported schemes SHOULD NOT themselves make use of
  TLS, such as the https scheme.

Making this limitation at the scheme level seems odd.  It seems possible to avoid the
circular dependency by saying that clients should not advertise this extension when
using TLS in retrievals.  Are there other issues here?
2006-06-07
09 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie
2006-06-07
09 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2006-06-07
09 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-06-07
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-06-07
09 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-06-06
09 Sam Hartman State Changes to IESG Evaluation from Waiting for Writeup by Sam Hartman
2006-06-06
09 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman
2006-06-06
09 Sam Hartman Ballot has been issued by Sam Hartman
2006-06-06
09 Sam Hartman Created "Approve" ballot
2006-06-05
07 (System) New version available: draft-housley-tls-authz-extns-07.txt
2006-06-02
09 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-05-31
06 (System) New version available: draft-housley-tls-authz-extns-06.txt
2006-05-30
09 Yoshiko Fong
IANA Comments:

Upon approval of this document, IANA will register the following:

Two new TLS extensions in the
http://www.iana.org/assignments/tls-extensiontype-values


client_authz
server_authz

One TLS supplemental data …
IANA Comments:

Upon approval of this document, IANA will register the following:

Two new TLS extensions in the
http://www.iana.org/assignments/tls-extensiontype-values


client_authz
server_authz

One TLS supplemental data type in the registry defined in the approved document
draft-santesson-tls-supp-02.txt (location to be determined soon):

authz_data

The IANA will also create the following new registries:

TLS Authorization Data Formats. The initial entries in the TLS Authorization
Data Formats registry will be:

0 x509_attr_cert
1 saml_assertion
2 x509_attr_cert_url
3 saml_assertion_url

TLS Hash Types. The initial entries in the TLS Hash Types registry will be:

0 sha1
1 sha256
2006-05-28
09 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2006-05-22
05 (System) New version available: draft-housley-tls-authz-extns-05.txt
2006-05-08
09 (System) IANA Action state changed to In Progress
2006-05-05
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-05-05
09 Sam Hartman Placed on agenda for telechat - 2006-06-08 by Sam Hartman
2006-05-05
09 Sam Hartman State Changes to Last Call Requested from AD Evaluation::AD Followup by Sam Hartman
2006-05-05
09 Sam Hartman Last Call was requested by Sam Hartman
2006-05-05
09 (System) Ballot writeup text was added
2006-05-05
09 (System) Last call text was added
2006-05-05
09 (System) Ballot approval text was added
2006-05-05
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-05-05
04 (System) New version available: draft-housley-tls-authz-extns-04.txt
2006-04-25
09 Sam Hartman State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Sam Hartman
2006-04-25
09 Sam Hartman State Changes to AD Evaluation from Publication Requested by Sam Hartman
2006-04-20
09 Sam Hartman Draft Added by Sam Hartman in state Publication Requested
2006-04-12
03 (System) New version available: draft-housley-tls-authz-extns-03.txt
2006-03-27
02 (System) New version available: draft-housley-tls-authz-extns-02.txt
2006-03-23
01 (System) New version available: draft-housley-tls-authz-extns-01.txt
2006-02-08
00 (System) New version available: draft-housley-tls-authz-extns-00.txt