RE: [security-services] AI-37 DSig Core change proposal

[<Frederick.Hirsch@nokia.com>]

Scott

Thanks for another excellent document. I have a couple of questions and comments. 

1) A minor nit, item #1 for the first bullet (signed assertion) might better read "Assertion integrity"
since this isn't a signed message but rather an assertion.

2)The note on alternate signing techniques isn't quite clear to me since I'm not sure whether it is referring to a SAML assertion, SAML protocol request or response, or SOAP message. In addition it seems pretty clear that XML Signature is the preferred mechanism given the close relationship of XML Signature to XML. I'm not sure what it means to use other signature mechanisms since they may break the consistent use of XML "packaging" - would that be harmful to interoperability? Are there SAML implementations that use alternate signing techniques that this note
needs to be retained? Should these other mechanisms be detailed? (Note that this is addressed later in 5.4.2 but
inheriting signatures means that the entire signature package must be maintained to allow verification (and do
we want to keep all that is signed with an assertion as we move it about).

Should we mention SOAP Message Security?

3)This paragraph is not clear to me (since it preceeds the following text about when assertions are signed):

Assertions:
"The asserting party has provided the assertion to the relying party, authenticated by means other than digital signature and the channel is secure. In other words, the RP has obtained the assertion from the AP directly (no intermediaries) through a secure channel and the AP has authenticated to the RP."

Perhaps we should replace this text as follows:

If an assertion is not signed, then it must be conveyed securely from the assertion authority to the 
relying party. This means that the channel must be protected for integrity and possibly confidentiality, and that
the relying party should be able to authenticate the authentication authority.

4) 5.4.3, s/insures/ensures/
5.4.7 s/insure/ensure/

5) 5.4.3
Should we remove this:
"Profiles MAY permit other methods, or recommend that specific methods be used or omitted, if it can be assumed that processing will not be affected in the application of the profile"

or do we want to say that canonicalization must allow signature verification outside the original XML context?



regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Monday, April 14, 2003 8:47 PM
> To: 'SAML'
> Subject: [security-services] AI-37 DSig Core change proposal
> 
> 
> Here's a replacement for section 5 of the core spec. I 
> change-tracked it from Eve's last draft, but that section 
> hasn't been touched
> yet anyway.
> 
> The substance is what I cribbed from the Liberty spec and 
> posted last week, with the basic layout adjusted to match the sections
> that were there from before.
> 
> Barring edits, I'd move for a vote on this text tomorrow so 
> we can put this to bed.
> 
> -- Scott
>