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

On Fri, Nov 21, 2008 at 1:24 PM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
>>> 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.


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

Understood, but this is completely out of scope.  An X.509-based PKI
may be leveraged by the SAML entities but this profile has nothing to
say about that.  I guess we need to drive that point home in the

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

I understand.  In that case, the IdP can do everyone a favor by
parsing the certificate (but as we've said, this is out of scope.)  As
an aside, note that <ds:X509Certificate> or <ds:X509IssuerSerial> is
required in this case to insure that the same certificate presented to
the IdP is subsequently presented to the SP.

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

Right, I think <samlp:AuthnRequest> satisfies this requirement.

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

Not in this profile.  If you want to profile something on top of this,
that's fine.  The general consensus in the SSTC, I believe, is that
the existence of an X.509-based PKI is out of scope.  At least so far
nobody has disagreed with that particular sentiment.

> What remains is a registration procedure at the IdP. The provisioning
> of "attributes" may use information from certificates.

Yes, but this has been deemed out of scope for the purposes of this profile.

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

Yes it is, and this needs to be made clear in the profile if it's not already.


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