RE: [security-services] comments re draft-sstc-metadata-iop-01

["Scott Cantor" <cantor.2@osu.edu>]

> - 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?

Yes, and yes. I didn't get around to it in the first draft but will add
something.

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

It's mostly about that, because most of the interoperability problems are in
that area, but it's not entirely about that, and the goal isn't to make only
that piece interoperable. As we have discussed before, we have different
opinions about the degree to which the original specification is already
quite clear on many things. But that doesn't mean that this document can't
include 
other clarifications if they don't belong in errata, so it is intended to be
a living document to some degree. Whatever makes this stuff work better I'm
willing to include (if I think it's actually useful).

>  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?

Abstract maybe, but I think the title is ok. The introduction of course is
pretty long and detailed.

> - It seems this is a "deployment profile" for SAML metadata rather
> than a general interoperability profile.

There's a fine line, but I think this is as general as it needs to be, and
still allows for many different deployment models.
 
> 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.

It doesn't rule out anything like that. It confines it to a specific part of
the implementation (and the deployment). The profile permits a very wide
range of deployment scenarios, including a very rigorous PKI. That has its
own downsides too, but that isn't my concern.

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

The section you're looking at is talking about metadata, not assertions.
Perhaps I should make that clearer. In other words, there's nothing here
that says you can't use SKI in a signature, only that it isn't defined for
use in metadata. Presumably, one could take an SKI in a message and use it
as a hint to identify which key in the metadata to try.

As a parallel point, though, you can argue that additional profiling to
constrain what a signature can contain is valuable in improving
interoperability. However, I would argue that experience suggests that in
fact very few KeyInfo options are used routinely by implementations, and
that there isn't a big problem there. The problem comes in how those few
options end up getting interpreted.

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

See above. I see no reason to allow for it in metadata. This profile is
already implemented, so I'm going to take a page from playbooks that plenty
of vendors have run with in the past. If it's not broken, the justification
to change it is going to need to be fairly strong.

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

I can try, but the sentence is fairly clear to me, and is somewhat
reinforced all over the text.
 
> - [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.

Good point. I don't think I can write normative language there that would be
meaningful even by my standards, so I'll rethink the conformance language.
 
> - [line 220] Is section 2.4 really a subsection of 2.3?

No. I didn't like the organization all that much, but there wasn't any good
place to include that issue. I also suspect that other assumptions will have
to be added as people study this, so I don't think that section will be
quite so off-putting once it's expanded a little. It may end up renamed
though, I'll think about that.

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

Well, it's not "against" it, it just isn't assuming that specific exchange
profile. I'll clarify that. The point here is to ensure that products that
currently don't support EntitiesDescriptor do so. I'm open to any text to
achieve that.

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

It's not meaningless to me. It also seems testable. You define a set of
valid keys for conformance testing, and you make sure that products generate
metadata with all of them, not just one. You probably also test other
aspects by expiring or invalidating a key and ensuring that products
properly omit that key (and so on).

Of course, that assumes a dynamic model, but it tests the requirement. In a
non-dynamic situation, it's a parallel requirement that any metadata source
can follow (which could also be tested).

Lastly, if the text isn't good, I need something that's better, because I
can't lose it altogether. Something has to be said.

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

I figured I'd wait and ask. I don't think we've done that in general, but I
don't care either way.

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

I don't have to define that, XMLSig already does.
 
> - [line 265] I don't believe normative "MAY" should be used here.

I'm torn on it, but I think you're right, at least in a passive voice. I
think it's an important statement though, so I might turn it around into an
active statement, and then I think it might be ok as MAY.

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

My own opinion is that conformance is a needless distinction when there
aren't choices. Part of the profile is to require this behavior, and I don't
want somebody claiming to "follow" the profile but just not conforming to
it. As I say above, I'm open to how to achieve my goal here, but I think
moving it to conformance just dilutes the locality of reference of the
requirement.

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

That's precisely the point. In this profile, the policy decision is whether
to accept the metadata, not the key. You have no choice on that, or there is
no point to the profile.

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

I don't follow. Why are they not used? If you mean that SAML doesn't have
constructs for encrypted messages, that's true, but I'll refer to your first
comment...this isn't just about SAML.

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

The parts that relate to cryptography are covered by other documents and
algorithms. Certainly I have nothing to say about how to process RSA or DSA
keys. The certificate case is special, and I provided text for that.

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

I don't care that there can be many certificates; in fact, that's exactly
why this requirement is there. I insist that all such certificates be
equivalent for the purposes of this profile. As an example, if you get a
Verisign certificate, use it for SSL, and register it in your metadata, I
insist that you MAY renew that certificate and (if the key is the same)
continue to operate successfully without updating your metadata. That is a
MUST.

(As an aside, the behavior you want was considered a defect in an earlier
implementation, and was reported by users as such.)

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

I'll try. It will probably take an example to understand.
 
> - [line 110, 205] Expand "PKI".

There's a loaded suggestion.

Thanks very much for the review.
 
-- Scott