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

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

On Fri, Nov 21, 2008 at 11:57 AM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
>
>>>> On Fri, Nov 21, 2008 at 8:58 AM, Peter Sylvester
>>>> <Peter.Sylvester@edelweb.fr> wrote:
>>>>
>>>>> 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 ...

The IdP MAY do this, yes.  Let me say, however, that the typical
scenario is for the IdP to bind a <ds:X509Certificate> element to the
assertion.  Unless the SP requests otherwise, this is the default.  It
is the simplest thing for an IdP implementation to do.  Although other
elements may be included (as you've noted), there's no particularly
good reason for the IdP to do so.

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

Yes, I believe that's true.  The easiest thing for everybody is to
handle the complete certificate (<ds:X509Certificate>), that's why
it's the default.

> Decoding a certificate is not a big deal

Well, as discussed in that lengthy thread in the IETF PKIX WG, this is
not necessarily so.

> but parsing pasring is:
> The way how additional information is coded in some certificate
> is very complicated, and normally inconsistent among CAs.

Indeed.  This is why we want to avoid this like the plague.  We don't
preclude the possibility that there's a well-defined X.509-based PKI
in place, but we don't expect it either.

> People code structures in private extensions, use/misuse AVAs,
> combine several pieces into one (maybe a subset of an) attribut etc.

Hey, you're preaching to the choir :-)  We know this.  That's why we
want to avoid it.

> Having an IdP  that knows all this an can present this to a SP
> in a normalised way seems pretty useful to me.

Well, I have to disagree.  We seem to agree that decoding and parsing
a certificate is hard.  That does not imply, however, that the IdP
should do it (as a favor to the SP).  To me, that simply means all
parties should avoid it, if at all possible.

> Who is determining the validity of the certficate? The IdP and/or the SP?

This question tells me we have to do a better job of explaining the
intent of this profile.  This is not your fault.  It means the profile
is lacking.

To answer your question, though, NOBODY has to validate the
certificate.  That's the point.  We are profiling holder-of-key
subject confirmation without requiring an X.509-based PKI.  That's why
this profile is so important, I think.

> The text only says that the holder must pass a test of possession.

Well, there are two things that have to happen.  One, the presenter
must prove possession of the private key via TLS, and two, the
presenter must authenticate to the IdP.  The fact that these two
events can be completely separate events is a key point that should be
driven home in the profile.  If you're not getting this from reading
the profile, then we have to do a better job.

Thanks for the feedback, Peter.  This is very helpful.

Tom