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

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

>> 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.
>
>   
As long as it is not excluded, an IdP can choose to provide additional 
service I guess.

>>>>>> 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.
>   
The complete certificat is indeed the easiest way to make a comparison
in TLS.
>   
>> 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.
>   
Decoding, parsing of content and signature validation are different things.
When I mentioned "simple", I wanted to say that one may perhaps need to
do a few hacks to be "tolerant" but this is nothing compared to
the semantics of fields, attributs etc.
>   
>> 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.
>   
But this is just the argument: If you have one IdP in a company 
infrastructure
and 1000 SPs i.e; web based applications ...

Logically authn and attributs are separated.
 From a practical programming standpoint of an SP, it seems desirable
that one uses only one communication with an entity that provides
an id and attributs.

Providing "additional information" about the iconfirmed dentity is useful,
whether they come from the cert or elsewhere by a directory lookup.
is another story.

>   
>> 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.
>   
You want to avoid to require any particular treatment as far as I see. 
That's ok.
Otherwise one would way: An IdP *MUST* provide a complete interpretation
of the content of a certificat in order to never  require an SP to do 
anything.
>   
>> 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.
>   
Yes. What remains is a registration procedure at the IdP. The provisioning
of "attributes" may use information from certificates.
>   
>> 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.
>   
Ok. So you replace the certficate checking or revocation
checking by some some mechanism at the IdP where the the IdP  needs
to be informed. no pb. It is the IdP that produces the result
that assumes that the identifier is valid. So the SP certainly
does not have to do this.
>   
>> 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.
>   
That was clear from the beginning, but what was not quite obvious
is what the SP or IdP is supposed to do concerning the cert.
The SP nothing, the IdP, whatever it wants. 
If the IdP chooses an implementation with some PKI backend to
do a more or less automatic provisioning of its database, this is still
possible.

The additional restrictions logic  of a subjectConformation may be
misleading. There should not be a restriction that requires the SP
to verify the revocation status of the certficat?

> Thanks for the feedback, Peter.  This is very helpful.
>   
Good.
Bon Weekend

> Tom
>
>   


-- 

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant Sécurité des Systèmes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : +33.1.40.99.14.14 / Fax : +33.1.40.99.99.58
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.com>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr 
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorité de racine 
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

S/MIME Cryptographic Signature