OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: comments re draft-sstc-metadata-iop-02


I'd like to make one additional comment:

On lines 286--288, it states that a <ds:X509SubjectName> element "MAY
appear, but MUST NOT be required in order to identify the key."  Yet
in the TeraGrid, an X.509-based grid that uses SAML to carry authn
context and attributes for the purposes of access control, the
<ds:X509SubjectName> element is used to map a SAML issuer to an X.509
issuer:

http://docs.google.com/Doc?id=ddj3qnj2_228hdzcdmhb

This is a legitimate use of the <ds:X509SubjectName> element, I think,
which seems to indicate that different deployments will tend to use
SAML metadata differently (no surprise, really).  In fact, this
alternate use of SAML metadata is the reason I referred to the
Metadata Interoperability Profile as a "deployment profile" as opposed
to some universally applicable profile.

Tom

On Mon, Oct 6, 2008 at 9:38 PM, Tom Scavo <trscavo@gmail.com> wrote:
> SAML V2.0 Metadata Interoperability Profile
> Document ID draft-sstc-metadata-iop-02
>
>
> General comments:
>
> - The SAML V2.0 metadata specification [SAML2Meta] requires that
> signatures be verified.  What if the consumer can not verify the
> signature?
>
> - A signature may appear on a RoleDescriptor or a
> AffiliationDescriptor element within an EntitiesDescriptor (or
> EntityDescriptor) element.  What if the consumer can not verify the
> signature on a RoleDescriptor or a AffiliationDescriptor element?
>
> - In section 2.5.1, are you suggesting that keys bound to certificates
> be called out in metadata with the <ds:KeyValue> element?  Why not use
> <ds:X509Data> exclusively in this case?
>
> - In section 2.5.1, you don't mention <ds:X509SKI> but as you know,
> this element is similar to <ds:X509Certificate> in that it
> unequivocally defines a key.
>
> - As noted in section 2.7, the validUntil and cacheDuration attributes
> are particularly important.  However, [SAML2Meta] does not adequately
> treat the case when they appear on a RoleDescriptor or a
> AffiliationDescriptor element within an EntitiesDescriptor (or
> EntityDescriptor) element
>
>
> Specific comments:
>
> - [lines 163--165] Why is this reference normative?
>
> - [lines 189--191] I think this should reference the Second Edition of [XMLSig].
>
> - [line 245] Is this subsection really needed?
>
> - [lines 257--258] I don't understand the normative requirement you're
> trying convey in this sentence.  Shouldn't this be a MUST?
>
> - [lines 258--260] I don't understand this sentence.  In what sense
> does this profile apply to the <md:RoleDescriptor> element?
>
> - [lines 278--279] This normative requirement is redundant since the
> previous section contains an identical requirement.
>
> - [lines 284--285] I don't see the point of allowing both forms in a
> single <ds:KeyInfo> element.  This could be a source of problems in
> fact.  For instance, how does a consumer process such a construct?
>
> - [lines 294--296] This requirement contradicts (in spirit, at least)
> section 3.1.5 of [SAML2Meta].
>
> - [line 307] The parenthetical remark on this line is unclear.  What
> does the pronoun "their" refer to?
>
>
> Suggested edits:
>
> - [line 179] s/S. Cantor/J. Hughes/
>
> - [line 195] s/S. Cantor/S. Whitehead/
>
> - [line 224] s/a public key infrastructure/an X.509-based public key
> infrastructure/
>
> - [line 225] s/as in/as specified in/
>
> - [line 268] s/i.e./i.e.,/
>
> - [line 311, 332, 346] s/e.g./e.g.,/
>
>
> Tom Scavo
> NCSA
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]