coments on draft-ietf-sacred-protocol-bss-00

I was reading over the latest draft last night 
(draft-ietf-sacred-protocol-bss-00.txt) and I have a few questions on 
things that confused me.

Section 2.1.2 introduces the "Create Account" operation.  It doesn't have 
any mention of a server wishing to only store credentials for authorized 
users or any way that a server might wish to authenticate a user before 
creating an account for them.  (For instance, a server might require 
authentication using a different SASL mechanism before allowing a user to 
create an account.)

Or a site with a preexisting authentication infrastructure might already 
have SRP authenticators to use, and there's no need for a user to upload a 
new SRP authenticator.

Thus, I think account management should be in a seperate section from the 
credential upload/download, and should be an optional part of the server to 
implement.  A baseline SACRED client/server has to support upload/download 
(that's the point) but not necessarily the account management.

Section 2.2: authorization identity must equal authentication identity. 
Why is there this restriction?  A client should be able to attempt to 
authorize as some other user; it's a server's site policy that determines 
whether or not this is allowed.  The easiest site policy is to always 
disallow proxying.

(Also, SASL allows a client to send the empty authorization string to 
"derive authorization from authentication credentials".)

Section 2.2: The mandatory to implement TLS cipher-suite appears to also be 
the the only one allowed:

   The mandatory-to-implement TLS cipher-suite for sacred is:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA. This MUST be used for both sTLS and
   cTLS cases.

Is this really what's intended?  Shouldn't a client and a server be allowed 
to use other cipher suites, as long as both support 
TLS_RSA_WITH_3DES_EDE_CBC_SHA so interoperability is guaranteed?

Section 2.3: why only one operation per connection?  I suggest instead that 
clients MUST be prepared to deal with servers that close the connection 
after a single operation and servers SHOULD support multiple commands per 
connection.  To simplify, you might want to say that commands MUST NOT be 
pipelined; the result of a previous command must be received before the 
next command can be sent.

Section 4.3: There should probably be error codes for "over quota" or other 
administrator limitations.

Appendix C: administrator operations: I don't see an overwhelming need to 
interoperate with administrative operations.  If there's a desire for this, 
further messages can be defined later.

Appendix C: mapping from SASL-SRP id to cTLS certificate: this is a very 
hard problem and is out of scope for SACRED.

References: There are many normative references to works in progress such 
as XKMS and XBULK. Is the working group concerned that there might be a 
long wait for publication?  Is xkms sufficiently far along?

[Bob Morgan shares credit for any of the insightful comments above.]

thanks,
Larry