Shibboleth2 IdP TrustEngine Extension using DANE, is it the right way?

[Cantor, Scott]

On 5/7/12 3:17 PM, "Christoffer Holmstedt"
<christoffer.holmstedt at gmail.com> wrote:
>
>We believe that it's a TrustEngine Extension that we should implement.

Probably, yes. I presume you are aware that unless the client (the IdP in
this case) is DNSSEC capable, this is not going to be secure.

>First retrieve the metadata as normal. With the domain specified in
>the name attribute from "md:EntitiesDescriptor", we will make a DNS
>request for CERT RR that are available. We will then match the
>retrieved CERT RR with the certificate available in the signed
>metadata file. If it's a match we continue otherwise the metadata
>validation will fail.

I'm not sure that matches what DANE intends a certificate RR to mean. I
had the impression they had not been willing to fully break with the CA
cartel and accept that keys alone should be what you're after. If you
still have to validate the certificate to proceed, you haven't gained much
(you can do some CA pinning and other slightly useful things, but you
can't fully break with PKIX).

I would not be so bold as to say this is "wrong" to do; we treat certs as
public key bags ourselves, so farbeit from me to cry foul, but I had the
benefit of having no spec to violate. Nothing tells us what KeyInfo
intends a receiver to do, so there's nothing to violate.

Also...

An EntitiesDescriptor Name isn't a domain, in general, so I don't know how
wise it would be to want it to be. It isn't even a URI, it's just a
string. It could be a domain, certainly, and that's a possible convention
one could use, but it isn't a spec requirement.

It might make more sense to deduce this from the domain of the URL at
which the metadata is published.

The problem is that because of DNS' limitations, among other reasons, SAML
does not use domains as names. Neither here nor in the case of entityIDs.
Given a URI, you can't in general even map that to a domain unless you
preclude URNs or assume URNs of a particular sort.

>Now to our questions:
>1) Are we on the right track with implementing a TrustEngine extension
>for this or are there better alternatives, something that we might
>have missed?

I don't think you're off track in terms of the extension point.

>2) We have found the already implemented ChaningTrustEngine and the
>others in org.opensaml.xml.security.trust but we're not sure which
>type is the proper one to extend (signatures, credentials or "other")
>as stated on the wiki [1]. Anyone able to shed some light on this one?

I believe it's a signature trust engine if you're trying to verify the
signer of an XML signature.

-- Scott