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

[Peter Sylvester <Peter.Sylvester@edelweb.fr>]

> Thanks, Peter.
>   
It's a pleasure. :-)
>   
>>> 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.
>   
Ok.
>   
>>>> 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.
>   
This means that the IdP parses the certficate and provides information 
in some
xml form to the SP ...

>   
>>>> 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.
>
>   
.. then there is no need at all to provide additional information like the
subjectName etc. at all.

Decoding a certificate is not a big deal but parsing pasring is:
The way how additional information is coded in some certificate
is very complicated, and normally inconsistent among CAs.

People code structures in private extensions, use/misuse AVAs,
combine several pieces into one (maybe a subset of an) attribut etc.
Having an IdP  that knows all this an can present this to a SP
in a normalised way seems pretty useful to me.

>>>> 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
>   
Who is determining the validity of the certficate? The IdP and/or the SP?
The text only says that the holder must pass a test of possession.

/P

S/MIME Cryptographic Signature