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


Thanks for the comments, Scott.

On Tue, Sep 30, 2008 at 11:01 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> Lines 152-155: missing references in PDF
>
> (side note: I'm pretty sure I figured out what causes these, if you haven't
> yet...fixing them generally requires accepting/rejecting changes that cause
> duplicate copies of the reference to be stored in the OO document).
>
> Line 170: "Extends" had a XML connotation when I first read it. How about
> "Supplements"?
>
> Line 197: Another missing reference.

Will fix all of the above.

> Line 214-216: I hadn't had a chance to report back the conversation with the
> XML-Security WG at W3C on the encoding question. This may be an acceptable
> approach, but do we want every profile to constrain this? The sense of the
> WG was that while other encodings are "legal", in practice there's no
> interop concern known around this because DER is the common convention. If
> we constrain it, then we're presuming it's the only one ever needed, and
> we're forced to constrain it repeatedly. We could say nothing, and leave it
> up to implemetations unless there's an actual interop issue that is causing
> problems.

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.

> Line 217-219: Is it defined someplace how to formulate the key for input to
> the hash?

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

Other methods (and other hash algorithms) are allowed.

I suppose I should say something about this in section 2.4.  I'll do
that in the next version of the profile.

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

> Line 223-225: I wanted to note that using IssuerSerial effectively precludes
> schema validation of a SAML assertion, because the XMLSig schema erroneously
> types the SerialNumber as a number and not a string. Large serial numbers,
> such as OpenSSL generates, blow through the numeric limits of common
> parsers.

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?

> Lines 275-276: I think this may be worded too strongly. I don't think the
> relying party can know in advance that the certificate is "known to be
> associated with the subject". That is, in fact, the *result* of processing
> the assertion. It's the goal, not the precondition. I think you mean that
> the certificate is "known to be associated with the presenter of the
> assertion"?

Will fix.

> Lines 314-315: I didn't follow this...what URI? Also it should be "a URI",
> not "an URI".

That sentence is referring to Issuer and is a holdover from a previous
version of the paper that described a corresponding request-response
protocol.  I'll either fix that sentence or remove it in the next
version.

> Lines 325-331: I have a hard time with suggesting that self-signed
> certificates would break anything but the absolute buggiest of code, but
> this notion of using a dummy CA would be preferable. This is the first I've
> heard of this draft, but color me unimpressed and rather dismayed by that
> hack.

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.  In any event, using certs issued by the Meaningless
CA precludes any problems that might occur, without requiring unneeded
infrastructure.

FWIW, an implementation of the Meaningless CA is readily available:

http://viewcvs.globus.org/viewcvs.cgi/gridshib/saml/tool/java/etc/meaningless-ca/

Interestingly, the end-entity certificate at the above location
contains a SAML assertion bound to a non-critical certificate
extension.

Tom


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