Subject: Re: WG last call on framework document.

From: "Nystrom, Magnus" <[email-masked]>
Date: Fri, 23 Aug 2002 11:19:16 +0200 (W. Europe Daylight Time)

> This message is to start a WG last call on the framework
> document. Since its summer (here) the last call will have
> a duration of one month, i.e. it ends on August 24th.

Here are a few editorial things I have found when reviewing this
memo. I do not think any of these warrants a new last-call period, but
perhaps others feel differently.

-Section 1, first paragraph: (and elsewhere) Replace "Private
 credentials" with "Digital credentials". First sentence could read:
 "Digital credentials, such as private keys and digital
 certificates,..."

 Reason: We are talking about digital credentials, private credentials
 are broader.

-Section 1, second paragraph: Replace "user credentials" with
 "credentials".

 Reason: It may be a host or some other entity's credentials.

-Section 2.1:

 a) Replace "private signing key credential" with "signature key".

 Reason: Shorter and clearer, that it is a credential has already been
 indicated.

 b) Replace "Credentials are cryptographically protected for
 confidentiality and integrity by encoding them in a standard
 format..." with: "Credentials may be cryptographically protected for
 confidentiality and integrity and encoded in a standard format..."

 Reason: Credentials are not necessarily protected, it is really up to
 the parties. And encoding them in a standard format is not needed to
 achieve this protection.

 c) Penultimate paragraph: Remove the reference to [PKCS15] and
 [PKCS12].

 Reason: They have already been referred to earlier on the page.

-Section 2.2, first paragraph: Replace "secure use and..." with
 "secure transfer and..."

 Reason: The document describes a protocol framework for transfer of
 credentials, not their use.

-Section 2.2, last paragraph:

 Replace "Prior to" with "During".

 Reason: It is the session/connection which is protected and hence is
 creating this second layer.

-Section 3, definition of "disconnect": Replace "operations that
 bound" with "operations that are bound".

-Section 3, definition of "Name-x": Remove the sentence "A credential
 name is required..."

 Reason: The intent was to allow, e.g. for deleting all credentials
 for a particular account. The current protocol document also does not
 require a name to be present

-Section 3.1, first paragraph: Replace "capability" with "operation"

-Section 4.1, first paragraph: Replace "conforming client and server
 implementations" with "conforming client implementations".

 Reason: Servers do not need to interpret the format.

-Section 4.1, second paragraph: Remove last sentence.

 Reason: Already covered in first paragraph.

-Section 4.2: In the list of examples of existing protocols that offer
 authentication services, replace "TLS authentication" with just "TLS"

 Reason: "TLS authentication" is not a protocol, TLS is.

-Section 4.2.2, second paragraph: Remove "CA root key".

 Reason: The root key is not strictly necessary, the client may have
 been configured to trust the server's public key directly.

-Section 4.2.2, paragraph starting "When necessary...": Replace "the
 server" with "the credential server" and replace "a SASL-based" with
 "an".

 Reason: a) clarity. b) the framework document should not assume
 SASL.

-Section 4.2.2, subsection "TLS with Remote Client Authentication":
 Change title, remove the word "Remote". Remoce last sentence in first
 paragraph (the sentence starting "Following...").

 Reason: a) Not needed. b) The server does not know if it has been
 succesfully authenticated or not. The sentence is not needed.

-Section 4.2.3: Remove the itemized list.

 Reason: It is not referred to, and requirements on authentication
 protocols are already in Section 4.2.

-Section 4.3: Just before the list of TCP, BEEP, and HTTP, insert:
 "Among these protocols are:"

 Reason: Clarity.

-Remove Section 5.

-Section 6: Replace "frameworksupporting" with "framework
 supporting".

-Section 6.1.3: Suggest shortening the text somewhat. E.g. replace the
 end of the sentence starting "These goals may be achieved..."
 (i.e. everything after "in which...") with "or explicitly." Change
 the start of the next sentence to "If the server...", and replace
 "root keys" with "trusted keys".

 Reasons: The paragraph is partially a repeat of text already in the
 memo, and references to what strong password protocols have already
 been made too. The last change is just to recognize that the
 important thing about these keys is that they are trusted.

-Section 6.2.1:

 a) "protocols secure" -> "protocols, secure"

 b) "In the case of a SACRED protocol" -> "In the case of a
    passwords-based SACRED protocol"

 c) Second paragraph: How is that to be done? Either some guidance or
    remove the paragraph.

 Reasons: b): SACRED protocols does not necessarily have to be
 password-based. c): If one is making such a statement some guidance
 ought to be provided.

-Section 7: The reference to PDM will probably have to go, the draft
 has expired and I could not find a new one.

-- Magnus

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 28 Aug 2002 14:03:52 -0500

Hi Magnus,

I think most of your suggested changes are excellent editorial
refinements.

I do have a couple of comments -- please see below.

Best Regards,

Dale Gustafson
Future Foundation Inc.
+1 651 452-9033 office
+1 218 343-9724 mobile

"Nystrom, Magnus" wrote:

> Here are a few editorial things I have found when reviewing this memo. I
> do not think any of these warrants a new last-call period, but perhaps
> others feel differently.

[ ... ]

> confidentiality and integrity by encoding them in a standard format..."
> with: "Credentials may be cryptographically protected for

Since the credential format is always opaque, "plain text" is certainly a
possible choice, depending on the security needs of the various SACRED
clients type(s) involved, etc.  However, I don't think we've given that
option a lot of thought since most of the discussion re: credential
formats has centered primarily on the PKCS#15 format and, to a lesser
extent, the PKCS#12 format.

Perhaps we could also add some more text indicating that the server should
ensure that it always handles stored and in-transit credentials as if they
are *not* protected by an inner encryption layer (e.g., that is part of
the credential format per se).

On second thought, using an unprotected credential format across a wide
variety of different clients seems like a questionable practice at best.
Anyone who does so is really on their own wrt adequately protecting
against credential (private key) compromise in all cases.

Do we really want to make this change?  Some other change?

[ ... ]

> -Section 3, definition of "disconnect": Replace "operations that bound"
> with "operations that are bound".

Suggest a different change:

     Note that “connect” and “disconnect” are logical,
     transport-layer dependent operations that inclose the protocol
     exchange between the two communicating processes.

[ ... ]

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 29 Aug 2002 15:41:52 -0700 (Pacific Daylight Time)

Dale,

Please find my answers inline.

On Wed, 28 Aug 2002, Dale Gustafson wrote:

[...]

> Do we really want to make this change?  Some other change?

It was since I felt we should concentrate on the protocol (and definitions
here), the credentials are really opaque (apart from that the protocol
document shall mandate one format for interop).  How about rewriting the
sentence to just: "Several standardized formats for the representation of
credentials exist, e.g [PKCS12], [PKCS15]." It is shorter and the fact
that they are to be protected is already apparent elsewhere, e.g. Section
2.2.

>      exchange between the two communicating processes.

Fine with me. "enclose" instead of "inclose"?

-- Magnus

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 29 Aug 2002 10:47:22 -0500

Hi Magnus,

Both of these are fine with me.

I agree these changes should not require another WG last call.  If anyone
objects, I guess now's the time to speak up.

Best Regards,

--dg