OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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


S/MIME Cryptographic Signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]