Transport Layer Security (TLS) Authorization Extensions
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
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 -)
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.