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

[Christoffer Holmstedt]

Inline answers below.

2012/5/7 Cantor, Scott <cantor.2 at osu.edu>:
> 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.
>

Yes, we're aware of this.

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

At the moment there is no mention of CERT RRs in the DANE use cases or
drafts. If we just look at the draft that is specfic to TLS
communication (http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/)
it will be up to the zone administrator or owner to choose whether you
want to have self-signed certificate or not.

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

Yes, we're aware of this. The first idea was to actually use the
domain of the URL at which the metadata is published, though I read
somewhere that within MetadataFilters or TrustEngines (can't remember
where or find it now for that matter) you only have access to the
actual downloaded metadata not the URL where it "comes" from. This may
very well be wrong so please correct me if so.

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

Thank you for your help Scott.
--
Christoffer Holmstedt