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

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

On Wed, Aug 13, 2008 at 1:27 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>
>> - 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.

AFAICT this profile is *entirely* about "the cryptographic
requirements" of SAML metadata.  There's nothing wrong with that, I'm
just suggesting that it be cast as such.

> 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 this profile contains no discussion about any of that, and I doubt
that it should.

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

Well you can add whatever you think is appropriate of course, but that
doesn't make this a general "Metadata Interoperability Profile."  For
that to happen, more than "the cryptographic requirements" of SAML
metadata would have to be discussed, and some of the very strong
language that is used would have to be relaxed.  I'm talking about the
normative language on lines 261--263 and lines 283--286, for instance.
 Those requirements virtually rule out the use of SAML metadata in
deployments that are already based on a PKI (such as a typical grid
deployment).

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

As I said, I think the title is misleading as it stands.

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

I think its a deployment profile, by your own definition.  There's no
question about this, in fact.

>> 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 certainly does.  For instance, on lines 261--263, the profile says
that other child elements of <ds:KeyInfo> "MUST NOT be required in
order to identify the key," but in a deployment that is already based
on a PKI (such a grid deployment), any of those child elements may be
used.

> The profile permits a very wide
> range of deployment scenarios, including a very rigorous PKI.

Well then I'm missing something, since lines 261--263 and lines
283--286 seem to rule out a PKI explicitly.  Please describe how a
grid deployment can use <ds:X509SubjectName> in lieu of
<ds:X509Certificate>, yet conform to this 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.
>
> 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.

That's not what I'm asking...why isn't <ds:X509SKI> defined for use in
metadata?  If all you care about is the key anyway, why wouldn't
<ds:X509SKI> in metadata serve the purpose?

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

There's already support for <ds:KeyValue> in your metadata
implementation?  I've never seen an example of such metadata so I must
be behind the times.

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

That erratum has particular relevance, I think.  It implies that
<ds:KeyValue> should only be used in the case where use="encryption".
Since use="signing" implies SSL/TLS as well, and the latter requires a
certificate, that implies that <ds:KeyValue> should not be used in
that case.

>> - [lines 257--258] What specifically is the content of each of these
>> elements?
>
> I don't have to define that, XMLSig already does.

It is customary for a <ds:X509Certificate> element to contain a base64
encoding of the DER-encoded X.509 certificate, but I can't find
anywhere in [XMLSig] where it says the certificate should be
DER-encoded.  Am I missing something?

I'll have to take your word about <ds:KeyValue>, which I've never seen
in a SAML metadata document (let alone a coded algorithm).

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

Sorry, I just think this paragraph along with the second paragraph in
section 2.6 are confusing.  You seem to be saying that the consumer
must accept each <md:EntityDescriptor> element without question, but I
don't buy that.  A consumer should be able to reject a particular
<md:EntityDescriptor> element outright ("I don't trust this entity").
Moreover, a consumer may choose to reject a particular key in an
<md:EntityDescriptor> element if, for example, it has learned (out of
band) that that key has been compromised.  Are you saying that a
consumer is not allowed to make such policy decisions?

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

Well, I meant that keys in metadata may also be used to encrypt
encryption keys (such as in the Attribute Sharing Profile).

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

In the case of a certificate, why must the consumer extract the public
key?  Isn't it more appropriate to compare the presented certificate
to the certificate in metadata?  (I know what you're going to say, but
I have to ask the question since this is the natural interpretation of
the <ds:X509Certificate> element.)

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

Yes, I understand that, and that's why it seems to make more sense to
put a <ds:X509SKI> element in metadata, not a <ds:X509Certificate>
element.  In other words, if you care about keys, use <ds:X509SKI>.
If you care about certificates, use <ds:X509Certificate>.

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

I think two sentences will provide more clarity.  Also, I don't
believe RFC3280 is the correct reference.  Seems RFC2818 is more
appropriate.

Tom