Transport Layer Security (TLS) Authorization Extensions
RFC 5878

Note: This ballot was opened for revision 09 and is now closed.

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Pasi Eronen) (was No Record, Discuss) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2009-10-14)
No email
send info
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)

(Robert Sparks) No Objection

(Adrian Farrel) Abstain

Comment (2009-08-02 for -)
No email
send info
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.

(David Ward) Abstain