Re: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-07

On Mon, Nov 10, 2008 at 2:48 PM, Scott Cantor <> wrote:
>> Perhaps you're right.
>
> Note, I'm not objecting to the text, much like in the other case, just
> suggesting it may not belong here.

Well, it does have the advantage of being explicit, all in one place.
Whether or not to include it here is a judgment call, I think.

>> In the case of HoK Web Browser SSO, the problem is likely associated
>> with the X.509 certificate obtained from TLS client auth (so the
>> RequestUnsupported status code is relevant, I think).
>
> In some cases, sure, but I don't think we need to require it. As a matter of
> interop, there aren't many cases where mandating a second level status is
> worth bothering with.

I don't feel strongly about it, I guess.  That said, I believe this is
a case where a status code might be useful to the SP, who says to
itself: "I can decode the certificate, but the IdP can't, so let me
back off and try the default."  Granted, this is very likely an edge
case.

>> There's not much we can do about this in the HoK Web Browser SSO
>> Profile except to perhaps RECOMMEND to the client to use a DER-encoded
>> certificate.  I doubt that recommendation is gonna make much
>> difference, however.
>
> Based on the feedback I'm getting, it pretty much makes no difference. The
> problem is that if people get non-DER certs, they're stuck with them. That's
> kind of the problem here.

Agreed.  The point of RECOMMENDING DER to the client is basically to
alert an implementer that there are potential issues here.

Tom