InCommon Technical Discussions

["Farmer, Jacob" <>]

Nick,

Thanks for posting the revision. It does not seem to include the information 
Dave shared from the Facebook policy. I think that would be useful 
clarification to have; by IU's brand standards, we would be required to use 
either a red or white background and I think Facebook's guidance about using 
a colored background or colored border is a good revision to add to the 
InCommon standard.

Also, I completely agree with having a standardized dimension, but I am not 
sure where this exact dimension came from. Has there been a survey done of 
widely-used identity selectors to make sure that resolution is commonly used? 
(and it's entirely possible this was done and I just missed that part of the 
thread)

Jacob

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Nick Roy
Sent: Friday, November 10, 2017 4:10 PM
To: 

Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata 
Requirements

Here's an updated version of the wiki, please review:

https://spaces.internet2.edu/x/4RL9Bg

Nick

On 11/10/17 8:52 AM, Nick Roy wrote:
> Nice
>
> I'm going to collate all the info from this discussion and update the 
> wiki page and our internal gdoc with the info today.
>
> Nick
>
> On 11/10/17 8:35 AM, David Shafer wrote:
>> FYI, here is Facebook’s policy for app icons, which seems to work pretty 
>> well:
>>
>> “4. Icons:
>> a. Use a transparent or colored background. If your icon requires a white 
>> background, use a colored border. 
>> b. If your logo has a drop shadow, use a colored background.”
>>
>> https://developers.facebook.com/policy/
>>
>> Dave
>>
>> -----Original Message-----
>> From: 
>> <>
>>  on behalf of Nick Roy 
>> <>
>> Date: Thursday, November 9, 2017 at 4:05 PM
>> To: Chris Phillips 
>> <>,
>>  "Farmer, Jacob" 
>> <>,
>>  "Cantor, Scott" 
>> <>,
>>  
>> ""
>>  
>> <>
>> Subject: Re: [InC-Technical] InCommon Baseline Expectations Metadata 
>> Requirements
>>
>>     I'll point out that the SSL test is a *recommended* piece but *not
>>     required* in the current specification of Baseline Expectations.
>>     
>>     To restate what I've heard so far:
>>     
>>     Logo URL:
>>     
>>     - results in a 200 via HTTP GET
>>     - is a PNG with a transparent background / alpha channel (because JPG
>>     does not support transparency)
>>     - is 80w x 20h
>>     
>>     SSL for endpoints:
>>     
>>     - subject to InCommon operations' running of SSL scans (exact nature to
>>     be determined by operations)
>>     - operations may save and act on information about the quality of SSL 
>> at
>>     its discretion
>>     
>>     (no minimum grade or other requirement related to SSL)
>>     
>>     errorURL:
>>     
>>     - results in a 200 via HTTP GET, other results cause a warning but not 
>> a
>>     full failure of the baseline tests
>>     (do we need to say something about 302 and maximum depth to chase
>>     referrals before lack of a 200 causes failure?)
>>     
>>     How does that look?
>>     
>>     Thank you,
>>     
>>     Nick
>>     
>>     On 11/9/17 8:47 AM, Chris Phillips wrote:
>>     > Great dialogue on this.
>>     >
>>     > Maybe it would be better to define what’s not acceptable regarding a 
>> grade and what’s a reasonable duration to remediate.
>>     >
>>     > Highest grade (A+) preferred but no lower than C on ssllabs and no 
>> longer than say X days below this band of acceptance.
>>     >
>>     > This gives latitude to maneuver when the tools change underneath 
>> one’s feet and dependencies to catch up. 
>>     > Jacob’s example is great in this regard. If his group didn’t care 
>> about it (or know to test that way) then how would he have pushed for the 
>> change to get back into compliance and hence pressured the vendor to step 
>> up?
>>     >
>>     > That said, things like Poodle SSLv3 and other future events we know 
>> will happen will change ranking from A+ to F overnight. Using the idea of 
>> X days to come into compliance allows us to respond commensurate with the 
>> risk.  It also allows us to simply be users of the tool which is not our 
>> core mission – we just want the output to inform our decisions.
>>     >
>>     >
>>     > C
>>     >
>>     > On 2017-11-09, 9:53 AM, "Farmer, Jacob" 
>> <
>>  on behalf of 
>> >
>>  wrote:
>>     >
>>     >     Nick,
>>     >     
>>     >     I like the Qualys SSL scanner and we use it often. Given my 
>> history, though, I 
>>     >     am reluctant to rely on it for this kind of thing. A real-world 
>> story from the 
>>     >     last few years: Qualys made a change to the scanner which caused 
>> sites we 
>>     >     manage that were in the A range to fall into the B+ range. I 
>> don't recall all 
>>     >     of the details about why; I think it had to do with cipher 
>> suites. Our load 
>>     >     balancer -- a widely deployed product on its current version -- 
>> could not be 
>>     >     adjusted to bring it back up to A. There was something in the 
>> configuration 
>>     >     that Qualys simply didn't like and there was no way to fix it 
>> until a vendor 
>>     >     patch shipped.
>>     >     
>>     >     I'm glad that we took the time to get it figured out, but I also 
>> don't think 
>>     >     that the quality of SSL was meaningfully degraded in the interim.
>>     >     
>>     >     I support the idea of defining "good TLS" but I am reluctant to 
>> rely on this 
>>     >     scanner to define it.
>>     >     
>>     >     Jacob
>>     >     
>>     >     -----Original Message-----
>>     >     From: 
>> 
>>  
>>     >     
>> [mailto:]
>>  On Behalf Of Nick Roy
>>     >     Sent: Wednesday, November 8, 2017 4:59 PM
>>     >     To: Cantor, Scott 
>> <>;
>>  
>> 
>>     >     Subject: Re: [InC-Technical] InCommon Baseline Expectations 
>> Metadata 
>>     >     Requirements
>>     >     
>>     >     
>>     >     
>>     >     On 11/8/17 1:58 PM, Cantor, Scott wrote:
>>     >     >> RECOMMENDED:
>>     >     >>
>>     >     >>    SSL certificates on endpoints are valid
>>     >     > That seems like a slippery slope: valid re: dates? Specific 
>> CAs? Key sizes? 
>>     >     > What about ciphers, or use of TLS 1.0, etc.?
>>     >     >
>>     >     > Requiring a logo is, I think, underspecified, we should 
>> mandate specific 
>>     >     > size(s).
>>     >     >
>>     >     > I'd like to see errorURL be required with guidance around what 
>> should be 
>>     >     > behind it.
>>     >     
>>     >     We think errorURL should be included as well, but since it was 
>> not part of the 
>>     >     'required' elements that AAC specified (AAC assumed errorURL was 
>> part of the 
>>     >     mdui: information, and it is not) that means this would have to 
>> go back to ACC 
>>     >     to make errorURL a separate required element.
>>     >     
>>     >     Agree re: specific requirements for SSL and logo.
>>     >     
>>     >     Here is my proposed requirement for SSL for endpoints (since 
>> it's recommended 
>>     >     but not required):
>>     >     
>>     >     - Achieve a grade of A on the Qualys SSL scanner [1]
>>     >     
>>     >     And for HTTPS Logo URL:
>>     >     
>>     >     - Must result in an HTTP 200 in response to a GET request
>>     >     - Image must be either a PNG or JPG
>>     >     - Image must be 80 pixels in width by 60 in height
>>     >     
>>     >     [1] 
>> https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
>>     >     
>>     >     Let me know if you think this is something that would better be 
>> discussed in 
>>     >     detail by the Ops Advisory Group or in some other venue.
>>     >     
>>     >     Thank you,
>>     >     
>>     >     Nick
>>     >     
>>     >     >
>>     >     > -- Scott
>>     >     >
>>     >     >
>>     >     
>>     >     
>>     
>>     
>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature