[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. > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]