InCommon Technical Discussions

[Mark Scheible <>]

>My anecdotal evidence talking with two professional graphic designers (I
>really did ask) is that the statement "background must be transparent"
>is reasonable and stated technically correctly so that any desinger can
>understand it.

+1

>My suggestion is to specify it and wait for the feedback that IdPs feel
>it is a burden to honor it, and only then consider lowering the bar.

+1

Mark

Mark A. Scheible

Sr. Lead IAM Solutions Architect

MCNC, Research Triangle Park, NC

Office: (919) 248-1997

Cell: (919) 609-8595

Fax: (919) 248-8419

On Thu, Nov 9, 2017 at 10: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
    >
    >