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: comments re draft-sstc-metadata-iop-01


Document ID draft-sstc-metadata-iop-01

General comments:

- The document title specifically mentions SAML V2.0, but does this
specification also apply to the use of SAML V2.0 metadata by SAML V1.1
entities?  Should this be mentioned?

- Although this specification is cast as a "Metadata Interoperability
Profile," I think its scope is much narrower.  To borrow a phrase from
section 2.5, I think this specification is about "the cryptographic
requirements" of SAML metadata.  Should the title and/or abstract
reflect the fact that the specification is about the security
requirements of SAML metadata, specifically the <md:KeyDescriptor>
element?

- It seems this is a "deployment profile" for SAML metadata rather
than a general interoperability profile.  The latter would also
address those deployments that operate within a traditional PKI.
Since this specification rules out such deployments (using very strong
normative language, I might add), I think this specification should be
cast as a deployment profile.

- Why is <ds:X509SKI> not mentioned in section 2.5.1?  I think
<ds:X509SKI> is a viable alternative to <ds:X509Certificate>.  For
instance, use of <ds:X509SKI> instead of <ds:X509Certificate>
significantly reduces assertion bloat.

- When should a producer use <ds:X509SKI> in lieu of <ds:KeyValue> and
vice versa?  I propose that <ds:X509SKI> be used if and only if the
key is obtained from an X.509 certificate.

Specific comments:

- [lines 113--115] I don't understand this sentence.  Can you rewrite it?

- [line 151] RFC 3280 has been obsoleted by RFC 5280.

- [line 184] There is no normative language in section 2.3 so it's not
clear exactly what a relying party is supposed to conform to.

- [line 220] Is section 2.4 really a subsection of 2.3?

- [lines 232--233] This sentence goes against section 2.3 of
[SAML2Meta].  Is this intentional?

- [lines 236--239] Use of the phrase "all cryptographic keys that are
known to be valid at the time of metadata production MUST appear"
leads to a meaningless requirement.

- [line 239] Erratum E62 has significant bearing on the reference
provided here.  Should it be mentioned?

- [lines 246--247] Join these lines to the previous paragraph.

- [lines 257--258] What specifically is the content of each of these elements?

- [line 265] I don't believe normative "MAY" should be used here.

- [lines 274--275] This sentence seems like a conformance requirement.
 Does it belong in section 1.4?

- [lines 279--282] I don't know what you mean when you say a key "MUST
be accepted."  It seems to me this is a policy decision, not a
normative requirement.

- [line 282] Keys in metadata are not used to "encrypt messages or
assertions."  Rewrite this phrase for accuracy.

- [lines 288--289] Specifically, how does a consumer process the
content of these elements?

- [line 290] I don't believe a consumer should extract the public key
from a <ds:X509Certificate> element since the same key may be bound to
multiple X.509 certificates.  Instead the consumer should match the
complete certificate (byte for byte).

- [line 294--298]  Sorry, I don't understand what you're trying to say
here.  Can you break this long, difficult sentence into two or more
sentences?

Suggested edits:

- [line 95] s/use/implementation/

- [line 110, 205] Expand "PKI".

- [line 112] s/revocation checking/revocation/

- [line 114, 122, 243] s/i.e./i.e.,/

- [line 164] s/S. Cantor/J. Hughes/

- [line 199] s/trust/trust information/

- [line 210, 249, 281, 295, 307] s/e.g./e.g.,/

- [line 204] s/following/conforming to/

Tom Scavo
NCSA


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