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

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

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

It is not entirely about that. Talking about EntitiesDescriptors as a MUST
has nothing to do with cryptography. Talking about requiring particular SOAP
authentication methods is also not really cryptography, although it's
motivated by those requirements.

What it is is a federation interoeprability spec that uses metadata to
achieve that. If it only talks about cryptography, then that just means the
rest of the metadata spec is working relatively well. I don't think I'm that
optimistic yet.

> But this profile contains no discussion about any of that, and I doubt
> that it should.

It absolutely should if there are outstanding issues.

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

That is a common mistake, but it's not true.

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

Let's see if anyone else is misled.

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

The question is whether it is general enough to address many different kinds
of deployments, and since I know for a fact that it is....

> 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 fact that it doesn't work for *a* deployment based on PKI doesn't mean
that it doesn't work for many others. The differentiator is where the PKI
is. Some people, wrongly IMHO, have been embedding PKI into the SAML
runtime. Those that use the PKI to protect the exchange of metadata will
find that their PKI composes perfectly with this profile.

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

In metadata? You can't. In a message? Feel free. As I said, I will
definitely clarify this, although the language is fairly clear on this now.
But it's important and easy to misunderstand.

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

Well....

- It's not interoperable now.
- I wasn't all that interested in making it interoperable.
- I'm not yet convinced that it isn't tied to X.509 in uncomfortable ways,
but this is open to discussion.
- I've never considered the question until now and my existing
implementation doesn't support it.
- It doesn't add anything new to the profile other than reducing metadata
size, and I'm not sure that I care enough about that yet.

That said, I'm not against it if people are using it now. I'm not convinced
they are.

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

It's been supported for going on 3-4 years now. People don't use it because
the syntax for bare keys is difficult. Certificates are more convenient to
deal with, and are generally around anyway because of TLS and historical
practice.

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

No, it doesn't. *Everything* in the metadata MUST be turned into a key.
That's the comparator. In the case of TLS, you extract the key from the
peer's certificate and if it matches, you're done. The certificate is a
runtime requirement, not a metadata requirement.

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

If not, I would say that's errata for them, because everything I've seen
codes only for that. Maybe there's an obscure reason why DER is somehow not
assumed, even though nobody supports anything else, but it's worth asking.
I'll certainly add something if I have to, but want to know more first.

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

It says precisely the opposite. There's a whole section devoted to the
notion of acceptance, the mechanics of which are out of scope.

> A consumer should be able to reject a particular
> <md:EntityDescriptor> element outright ("I don't trust this entity").

And it can.

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

That one is a finer point, but the effect of such a revocation is simply to
remove it from the metadata. Perhaps a better way to say this is that as an
implementer you are not *obligated* to expose such a mechanism other than
through the consumption of metadata.

The point is that if we open the door to CRLs, we've lost. Somehow that has
to be prevented, ideally without being so specific that something like a CRL
doesn't sneak in.

I agree this text needs a little work.

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

That's why it states explicitly that the natural interpretation doesn't
apply. If I have to motivate it, it should probably go in security
considerations, but I consider that optional, and more a topic for
discussion. I believe I motivated it in my last email. It has to do with
decoupling certificate renewal policies from metadata. It has been
critically important in practice.

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

The profile will never care about certificates, but interoperability and
simplicity demand that certificates be permitted with precise rules for
their use that doesn't expose a SAML runtime to the complexity of PKIX.
Having done that, SKI never came up.

People know how to stuff PEM into metadata. That's easy. Computing an SKI
isn't (for humans). The point being that adding a second mechanism is just
that; it doesn't supersede the first one.

And lastly, again, this interpretation of certificates is implemented in
multiple versions of deployed software. I can pull the profile, but I can't
change it other than through addition without defeating the purpose. Adding
SKI is (sort of) fine, but changing how the mechanics work isn't something I
can change now.

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

I got the reference from somebody else, but I was a little skeptical of it
myself.

-- Scott