OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


> There is no interop issue that I'm profiling for, no, but if some
> implementation were to do something different, there would be an
> immediate interop issue since, as you say, DER-encoding is used
> consistently by today's implementations (as far as I know).  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.

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

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

> 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

if that doesn't help, I can write something eventually.

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]