Re: WG last call on framework document.

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


"Nystrom, Magnus" wrote:

> Dale,
>
> Please find my answers inline.
>
> On Wed, 28 Aug 2002, Dale Gustafson wrote:
>
> [...]
>
> > "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?
>
> 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.
>
> > > -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.
> >
> > [ ... ]
>
> Fine with me. "enclose" instead of "inclose"?
>
> -- Magnus