Re: WG last call on framework document.
"Nystrom, Magnus" <[email protected]> Thu, 29 Aug 2002 15:41:52 -0700 (Pacific Daylight Time)
| Newsgroups | gmane.ietf.sacred |
|---|---|
| Message-ID | <Pine.WNT.4.44.0208291530350.812-100000@mnystrom-lap2> |
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