Securely Available Credentials Protocol
RFC 3767

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

(Steven Bellovin) Yes

(Ned Freed) Yes

(Harald Alvestrand) No Objection

(Margaret Cullen) No Objection

Comment (2003-09-18 for -)
No email
send info
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.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2003-09-17)
No email
send info
Comments on draft-ietf-sacred-framework-06:

  In section 5.2.2, plaease make three changes:
    - Change "x.509" to "X.509"
    - Change "trusted SACRED roots" to "SACRED trust anchors"
    - Change "roots from other applications" to "trust anchors from other applications"

  Please change the title of section 5.2.4 to "Denial of Service."

Comments on draft-ietf-sacred-protocol-bss-08:

  Throughout the document, please change "privacy" to "confidentiality."

  In section 1, please change "(confidentiality, authentication, etc.)" to "(integrity, authentication, and confidentiality)."

(Thomas Narten) No Objection

(Jon Peterson) No Objection

Comment (2003-09-18 for -)
No email
send info
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?

(Bert Wijnen) No Objection