[security-services] Stylized sec-consider-02a draft

["Eve L. Maler" <eve.maler@sun.com>]

Chris said it was okay for me to send my take on sec-consider to the TC at 
large.  I tried to keep the changes technically neutral, but I may have 
screwed up, so people should give it a once-over just in case.  Also, I 
inserted some text from the bindings doc that may need to be removed from 
one place or the other; this should be done before it gets published.  (I 
assume Prateek and Chris can safely negotiate this; if anyone doesn't think 
that's the case, speak up now!)

Below are the comments -- mostly editorial, but some possibly affecting 
meaning that we may have to take up in coming weeks -- that I sent to Chris 
when I finished work on this.  I'm sending them to this list for the 
official record.

	Eve

			*		*		*

- I added some Word "post-it comments" here and there to indicate obvious 
holes in the draft.  Some were previously red text, and some I added 
unilaterally.  These will want to be removed before publication.

- We need to rationalize the list of contributors on all the documents 
before we publish them on January 9.  It has been suggested that we use the 
list of all regular attendees.

- A few acronyms that aren't expanded and aren't defined are CRL and 
CA.  These probably should appear in the Glossary too.

- Section 4, lines 750 ff.: The URLs for SAML documents that *appear in* 
all the SAML documents will need to be updated to reflect the final draft 
number we use on January 9.  Alternatively, we should copy the latest live 
version of each document to draft-sstc-sec-consider, draft-sstc-bindings, 
etc. so that URLs can remain consistent.  (W3C does this sort of thing.)

- Section 1, line 95: I added the descriptor "non-normative" to the 
description of this doc because I think that's what it is meant to be.  If 
this is not the case (and the determination of this probably depends 
heavily on the relationship between this and bindings-08), then a note 
about RFC 2119 notation and a bibliographic entry for this RFC should be 
added; both can be stolen from bindings-08 or core-23.  Also, the text 
should be examined very carefully for places where things like "MUST" 
should be used in the special sense.  Right now, the only such text already 
existing is in the imported bindings-08 material (see below for more about 
this).

- Section 2, lines 158 ff.: Currently, confidentiality, data integrity, and 
cipher suite are not in the Glossary; I think it would be a good idea to 
add them.

- Section 2.1, lines 161-163: Authentication means something different here 
compared to a SAML "authentication assertion", right?  This may be 
confusing to a lot of security geeks and others.  If there are two real 
definitions, we should clarify here and in the Glossary what's going on.

- Section 2.4, lines 201 ff.: Should bindings-08 remove its information on 
cipher suites in favor of the information appearing here?  Is there some 
normative/non-normative line that can easily be drawn so that we don't have 
duplicated information (which will be hard to maintain at the very least)?

-
Section 3.3, line 341: Here and elsewhere, XML Encryption was talked about 
as if it didn't exist yet.  It's a draft, but it certainly does exist, and 
it's no less normative than XML Signature (which is farther along in the 
process but is still not a W3C Recommendation/IETF RFC).  I changed 
everything to reflect this fact. S'okay?

- Section 3.4: This is a big issue and it affects bindings-08 as much as 
this document: Should SOAP/HolderOfKey and SOAP/SenderVouches be two 
separate profiles, much as browser/artifact and browser/POST are now two 
separate profiles?  It would seem to make things clearer when it comes to 
people saying what profile they conform to.  (This type of detail is no 
doubt why cipher suites adopted that ugly naming scheme...)

- Section 3.4, lines 449-450 and 455 and elsewhere: The question of whether 
HTTP is "over" or "under" SSL/TLS is inconsistent in several places in this 
document.  It needs to be rationalized.

- Section 3.4.2, lines 533-598: The original red text was a copy of an 
earlier version of some sections of the bindings document.  For now, I 
imported the relevant text from bindings-08.  Is that okay?  Note that the 
"Threat: Countermeasure:" style used in the bindings document, along with a 
few other stylistic things, is different from the usual style in this 
document.  Also, some of the imported text is now slightly out of context 
(e.g., references to "Steps 4 and 5").

- Section 3.4.3, lines 608-652: Same as the above.

- Section 3.4.4.1.1, lines 663-673, and Section 3.4.4.2.1, lines 713-723: 
These are identical; it seems that there needs to be a "common threats" 
section for both formats of the SOAP profile (or, said another way, both 
profiles, depending on what we decide to do with the number of profiles).

draft-sstc-sec-consider-02a.doc

--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com