Re: [security-services] Comments on Attribute Sharing Profile for X.509 Authentication-Ba sed Systems (draft 10)

["Tom Scavo" <trscavo@gmail.com>]

Tom, many thanks for looking this over.  May I ask precisely what
document you're referring to?  Is this a document I mistakenly
attached to an e-mail or is it one of the documents I uploaded to the
repository yesterday?

Thanks again,
Tom

On 7/7/06, Thomas Wisniewski <Thomas.Wisniewski@entrust.com> wrote:
>
>
> Tom, here are some comments. In general, I like how you've reworked the
> sections.
>
> 1. line 183: s/value of/value is/
>
> 2. line 249: s/5.2.2/4.2.2/
>
> 3. lines 379-381 and 423-425 -- I suggest that you remove these lines. When
> using metadata, the use="encryption" attribute is typically used for
> including a public key or X509 certificate (for example) that is used by the
> metadata user to encrypt a symmetric key. The symmetric key is *not* a
> previously established key. Actually if you did have a previously
> established key, you would not need to encrypt it (as it would not be sent
> over the wire).
>
> 4. lines 392 and 439 (in relation to the above stmts) s/encrypt symmetric
> keys/encrypt previously established symmetric keys/
>
> 5. line 481-486  Add the following thought somehow. Basically,
> transport-level security alone will not provide SAML message authentication
> of the sending party. I.e., a receiver can authenticate any requesting party
> it trusts and that will provide confidentiality and message integrity.
> However, it does not satisfy the requirement that the message (SAML xml
> content) sent is in fact coming from the authenticated requester. For
> example if the receiver trusts requester A and requester B. What if
> requester A sends a SAML message stating that its IssuerName is that of
> requester B. Strictly tranport-level security would not suffice. So either
> XML signatures is required or SAML message authentication is required.
> So for Enhanced Mode, transport level security would not suffice in
> single-hop scenarios (the current text implies it would be ok -- and the
> need for dig signatures is really because of the possibilitly of multi-hop
> scenarios).
>
> Tom.
>
> Thomas Wisniewski
> Software Architect
> Phone: (201) 891-0524
> Cell: (201) 248-3668
>
> Entrust̉
> Securing Digital Identities
> & Information
>