Re: [security-services-comment] Additional certficate information

["Tom Scavo" <trscavo@gmail.com>]

On Fri, Nov 21, 2008 at 9:59 AM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> 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
>> <Peter.Sylvester@edelweb.fr> 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