Securely Available Credentials Protocol
draft-ietf-sacred-protocol-bss-09

[Note]: 'Was part of a ballot set, the other document was published as an RFC, but this document is still in the RFC Editor''s Queue.' added by Amy Vezza

[Ballot comment]
protocol-bss-08 describes a "create account" operation that is not discussed in any significant detail in the framework (though RFC3157 requirement S13 substantiates this need). I think the framework document could use a little text that describes the overall process of creating an account at a SACRED server. What sort of association does a user need to have with a server for this sort of self-enrollment to work (what is the applicable trust model of self-enrollment)? What are the risks of uploading credentials to a server with which you have no association (e.g. are there risks of initial man-in-the-middle attacks when self-enrollment takes place)? How do clients anticipate the structure of identifiers (usernames/credential namespaces under which they attempt to enroll) at SACRED servers with which they have no association?

[Ballot comment]
draft-ietf-sacred-protocol-bss-08.txt could be greatly enhanced by adding
an introduction.  The section that is labeled "introduction" doesn't
seem to contain an introduction to either the document or the protocol.

Also, why doesn't this document contain an informative reference to the
framework document?  I read them in the wrong order, and it was much
easier to understand draft-ietf-sacred-protocol-08.txt after I read
draft-ietf-sacred-framework-06.txt.

draft-ietf-sacred-framework:

Nit: abstracts should be one paragraph, and not contain references.
A reference to a mailing list is even worse.


----------
draft-ietf-sacred-protocol-bss:

Nit: the abstract is inadequate, and shouldn't contain URLs or mailing
list names.

2.3.1: what about AES as mandatory-to-implement?  At the very least,
it's a SHOULD.  (See RFC 3268)

-----------
both:

More discussion is needed about server authentication.  In particular,
there's no discussion about how a client might *know* that it's dealing
with the correct server.  One of the uses for SACRED discussed early on
was for things like Internet kiosks, where there's no pre-configured
information in the actual client software.  The protocol document must
discuss what protocol elements are verifiable, against what inputs
(i.e., the TLS certificate, if that's your choice); the framework
document should discuss the broader question, including user interface
issues.