Comments on sstc-saml2-holder-of-key-draft-03

["Scott Cantor" <cantor.2@osu.edu>]

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.

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.

Line 217-219: Is it defined someplace how to formulate the key for input to
the hash? 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?

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.

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

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

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