Re: [security-services] Comments on sstc-saml2-holder-of-key-draft-03

["Tom Scavo" <trscavo@gmail.com>]

On Thu, Oct 2, 2008 at 11:04 AM, Scott Cantor <cantor.2@osu.edu> wrote:
>> ...  Thus I
>> don't see how we can do anything but confirm current practice, that
>> is, specify a DER-encoding.
>
> I kind of botched that explanation...here's another try. What they told me
> was that, essentially, this is something the ASN.1 library somebody is using
> would have to handle, and that the encodings that people use are widely
> supported. Mostly DER, but also BER, etc.
>
> The analogy, I think, would be to XML character encoding. We don't specify
> that in SAML, because it's assumed that you're using a conformant parser
> that handles what it should, and people pick encodings that are likely to
> work. If you chose to use some weird, optional encoding, you'd know that you
> were risking a problem, and presumably had a reason to.
>
> I think the same idea would hold here.
>
> Hopefully the other W3C-ites like Frederick or Hal could chime in and let me
> know if I'm relaying this accurately.

Okay, I think we should discuss this issue on the next call.

>> RFC 5280 RECOMMENDS one of two methods described in section 4.2.1.2.
>> The first of these methods is most often implemented in practice (as
>> far as I can tell):
>>
>> "The keyIdentifier is composed of the 160-bit SHA-1 hash of the value
>> of the BIT STRING subjectPublicKey (excluding the tag, length, and
>> number of unused bits)."
>
> Ok. No idea what what means, but presumably others do.

I'll elaborate in draft-04.

>> > Also, is SHA-1 what we want to bake into a profile at this point?
>> > Hash vulnerabilities aren't my specialty, maybe the weaknesses aren't an
>> > issue here?
>>
>> That's a very good point, but I feel we need to specify something.
>> What do you suggest we do?
>
> If there's a material concern about SHA-1, I'd say use SHA-256 or something,
> otherwise just leave it.

Well, RFC5280 is pretty clear about this so I'll leave it as SHA-1
unless someone comes up with a VERY good reason to change it.

>> Ouch.  I think this deserves a paragraph in the "Security and Privacy
>> Considerations" section.  Can you point me to a written summary of the
>> issue, or barring that, would you be willing to write some text?
>
> Here's a bug report, and it has a link to a bug report on the most common
> parser people use with C:
>
> https://bugs.internet2.edu/jira/browse/CPPXT-14

Thanks, that helps.

>> Well, an implementation that does path validation does so in light of
>> profiles that clearly distinguish between CA certificates and
>> end-entity certificates (by means of certificate extensions) so it
>> should come as no surprise that self-signed end-entity certificates
>> cause problems.
>
> If you're using self-signed certificates, though, you don't do path
> validation. And if you're accepting a bogus CA, you obviously don't need to
> do it, so why would one assume that validation is even happening?
>
> What I mean is, if you need validation, obviously the bogus CA won't fly. If
> you don't need it, then your implementation should be prepared to handle
> that.
>
> Specs shouldn't define for the broken case, they should force those with
> broken software to work around the bugs so that when the bugs get fixed, the
> hacks drop out.

Yes, I see what you're saying, and I don't disagree.  I will take out
that paragraph (and the reference) if you feel strongly about it.

Tom