Assurance

[Tom Scavo <>]

On Fri, May 2, 2014 at 11:50 AM, Eric Goodman 
<>
 wrote:
>
>> > 2) Signatures on certificates used in IdP Signing/Encrypting
>> operations.
>
>> If you're talking about certificates in metadata, no, there is no
>> security concern there since the certificate wrapper on public keys in
>> metadata is wholly irrelevant. (If there were sufficient tooling to
>> handle bare keys, we'd probably be doing that.)
>
> So basically, the key being in metadata, associated with a specific set of 
> endpoints proves the provenance of the key itself, irrespective of the 
> signature.

Yes.

> And since the metadata (for InCommon at least) is signed with SHA-2, then 
> presuming you validate the metadata's signature when you consume the data, 
> then you’re “transitively” using an Approved Algorithm.

I don't think metadata consumption is addressed by any of the
assurance profiles but the technical answer is yes---if you can verify
the signature on production metadata (which uses a SHA-2 digest
algorithm), you can undoubtedly verify a similar signature on a SAML
assertion. That assumes your metadata client is closely tied to your
SAML SP, which in the case of Shibboleth and simpleSAMLphp (the two
implementations we recommend) is definitely true.

> I'm wondering if there's still a compliance requirement for those that are 
> not auto-consuming (and validating) metadata.

I'm not sure how to answer that question except to say "not
applicable" but someone else may have a different interpretation,
however.

>> > Compliance Concerns: Key rollover could be required. Any SP
>> > compatibility issues?
>>
>> There are no compatibility issues with software that's doing the Right
>> Thing.
>
> I think that's a given, no? :)

What I mean is the metadata trust model used by the InCommon
Federation (called "Explicit Key") attaches no relevance whatsoever to
the certificate wrapper on public keys in metadata. Not all SAML
implementations conform to the trust model, which is why we have so
many recommendations regarding certificates in metadata.
(https://spaces.internet2.edu/x/boY0) If you want to interoperate with
"other software" (https://spaces.internet2.edu/x/ioHPAg), you need to
be careful about certificates in metadata.

Perhaps the worst thing you can do is use a CA-signed certificate in
metadata since such certificates contain extensions that "other
software" actually pay attention to. For example, some software is
known to actually query an OCSP endpoint in a certificate extension.
In the very least, that will slow down SAML Web Browser SSO
unnecessarily.

Here's a case in point: If the MS Windows platform stopped accepting
SHA-1 signed certificates altogether, we'd be in hot water since there
are many AD FS deployments in the Federation that *do* pay attention
to the certificate wrapper on public keys in metadata.

> ------------
>> > 3) Signatures on assertions
>> >
>> I just ran my scripts today, in fact. I tested a total of 2397 SAML2
>> HTTP-POST AssertionConsumerService endpoint locations in SP metadata.
>> Of those, only 7 tested positively incompatible with SHA-2. There are
>> 100s of endpoints that gave inconclusive results (dead endpoints,
>> timeouts, inconsistent responses, etc.) but I consider this to be a
>> indicator of wide compatibility with SHA-2.
>
> The testing web page at 
> https://spaces.internet2.edu/display/InCAssurance/Transition+to+SHA-2 
> doesn't contain those results. Might be worth linking to them from those 
> pages if you have the results published. (The translation pages make it 
> sound much more worrisome that the discussion of the results do).

I'll take a look at it but I can summarize the results here since
they're simple to state: After June 30, 2014, almost all SPs in the
InCommon Federation will be compatible with SHA-2.

>> > Individual SPs
>> > (those not in InCommon) would need to be tested, well, individually.
>>
>> Yes, and the best thing they can do is to point their metadata refresh
>> process at the production metadata aggregate: [...]
>> since it is signed using a SHA-2 digest algorithm. If they can consume
>> that metadata, then they can almost certainly consume a SAML assertion
>> signed using a SHA-2 digest algorithm.
>
> I was largely thinking of providers who don't leverage (or validate) the 
> metadata

Such SPs have a much larger problem than SHA-2 compatibility. I
wouldn't be building my IdP deployment strategy based on that minority
of SPs.

Tom