Assurance

[Eric Goodman <>]

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

I know there are SPs that manually or programmatically copy entries from 
InCommon metadata (or from the IdP operator) without verifying the 
signatures. It's entirely possible that an IdP might do the same for some or 
all of its SPs. I was just saying that an IdP doing so may not be meeting the 
letter of the "Approved Algorithm" requirement if you compare it to front end 
TLS (where cryptographically validating the provenance of the cert with a 
digital signature is implicitly considered part of the requirement to be 
"Approved").


> Perhaps the worst thing you can do is use a CA-signed certificate in
> metadata [....]

I was not arguing that CA signed certs should be in metadata, I was positing 
that validation of metadata (to verify the keys in the metadata) using 
digital signatures stronger than SHA-1 (or at least more FIPS 140-2 Approved 
than SHA-1) may be required for the communication to be considered an 
Approved Algorithm between the IdP and the SP.


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

Understood. I suggested this as someone who was independently looking for 
information on testing status, found some information about early failed 
tests and couldn't find current testing status without asking you. :)


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

We all run into vendors that have all forms of custom ways of configuring 
their clients. We're not always able to force such SPs to do the Right Thing. 
Given that there's no non-drastic way to segregate an intransigent SP 
provider (should you be working with any), this could be an issue in 
reconfiguring to be in compliance.

Hopefully it's clear that I'm not asking about recommended best practices; 
I'm trying to identify areas where current practices may need to change to be 
compliant given the SHA-1 change in status, and possible real-world impacts 
of making such changes. 

Have a good weekend, and thanks for all the feedback.

[And to anyone still reading, I'm still interested in whether SSHA passwords 
in LDAP userPassword fields would still count as Silver-compliant.]

--- Eric