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