Re: WG last call on framework document.

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:

> > 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.

[ ... ]

> 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.

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.

[ ... ]

>
> -- Magnus