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

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

Tom, thank you for providing these comments.  I assume you're
referring to draft-10-diff.pdf.

On 7/7/06, Thomas Wisniewski <Thomas.Wisniewski@entrust.com> wrote:
>
> 1. line 183: s/value of/value is/

I can't verify this typo.  Is this from a different version of the document?

Oh, I see what you're saying.  You're using the 's' notation
differently than what is typically done. A kind of "reverse polish
regex operator," huh? :-)

It's not a big deal, but I think "value is" is the correct wording in this case.

> 2. line 249: s/5.2.2/4.2.2/

My fault, this is merely an artifact of the diff.  If you check
draft-10.pdf (no diffs) you'll see that the ref is correct.  (Sorry, I
haven't yet figured out how to effectively use OpenOffice.)

> 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).

You're right of course.  Thanks for pointing this out.  Would the
following re-wording suffice?

[lines 379--381] To permit service providers to encrypt symmetric keys
in accordance with this profile (section 4.2.2), there SHOULD be at
least one <md:KeyDescriptor> element with attribute use="encryption"
in identity provider metadata.

[lines 423--425] To permit identity providers to encrypt symmetric
keys in accordance with this profile (section 4.3.2), there SHOULD be
at least one <md:KeyDescriptor> element with attribute
use="encryption" in service provider metadata.

> 4. lines 392 and 439 (in relation to the above stmts) s/encrypt symmetric
> keys/encrypt previously established symmetric keys/

Agreed.

> 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).

This is an important comment.  I need to think about it.

Thanks,
Tom