[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]