On Fri, Nov 21, 2008 at 9:59 AM, Peter Sylvester
<> wrote:
> Tom Scavo wrote:
>>
>> Peter, when you refer to a draft, please specify the draft number (or
>> the document id) and the document type (PDF or whatever). There are
>> many drafts of the HoK Web Browser SSO Profile.
>
> sstc-saml-holder-of-key-browser-sso-draft-09.pdf
> sstc-saml2-holder-of-key-draft-06.pdf
Thanks, Peter.
>> On Fri, Nov 21, 2008 at 8:58 AM, Peter Sylvester
>> <> wrote:
>>
>>> As a follow up to my comments during the last days and this morning.
>>>
>>> 1:
>>> Line 424 of the browser-sso-draft says:
>>>
>>> 'Other certificate information MAY be included in additional child
>>> elements
>>> of the <ds:X509Data>
>>>
>>> The restrictions of holder-of-key concerning the choice that can be
>>> selected
>>> in
>>> the X509DataType doesn't seem to prohibit to add arbitrary elements of
>>> the
>>> <any> choice.
Correct.
>>> If my reading is correct, one can include for example the XER encoding of
>>> a
>>> certificate at that place simplifying the parsing of the certificate.
>>> Or a sequence of saml attributs
That is true, I suppose. I don't believe that's what Nate had in mind
when he wrote that sentence, however. I think he means that other ds
namespace qualified elements may be included, such as
<ds:X509SubjectName> and so forth.
>>> 2;
>>> Line 447ff permit to use other information from the certificate for
>>> whatever
>>> other purpose.
>>> This can obviously by decoding the certificate, but IMO it is not
>>> prohibited
>>> to
>>> have additional elements in the X509Data prepared by the ID provider.
That's true, but this is simply out of scope. Moreover, I see no good
reason for the IdP to parse the certificate for the SP, so I don't
think this even deserves a mention.
>>> 3:
>>> What is the reason for disallowing X509CRL ? (Not that I want them).
The point of this exercise is to profile holder-of-key subject
confirmation, and as far as I can tell, binding a CRL to the assertion
does not facilitate holder-of-key subject confirmation. A CRL is used
to validate a certificate (right?) and since we assume there is no
trust relationship between the SAML entities and the certificate
issuer, a CRL serves no purpose.
Now it's true that the use of elements <ds:X509SubjectName> or
<ds:X509IssuerSerial> require such a trust relationship, but again
it's not the IdP's job to supply the SP with CRLs that it can use to
validate the certificate (or at least so I think).
Tom
