[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on sstc-saml2-holder-of-key-draft-03
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]