[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Groups - sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf uploaded
Ari, thanks for the comments. Please find my responses below. Tom On 8/15/06, Ari Kermaier <ari.kermaier@oracle.com> wrote: > > > > [line 20, et al.] Is there a reason that the profile should > > > not specify X.509 v3 certificates, but leave it open to the > > > possibility of v2 or (shudder) v1 certs? I think we need to > > > examine the potential implications to see if this is a > > > substantive change that broadens the scope of potential > > > interoperability issues. > > > > Please see lines 106--107. As defined, the term "X.509 certificate" > > references RFC 3280, which I believe precludes anything less than v3 > > certificates. > > > > I'm open to clarifying this further if need be. What I tried to do > > was not limit the discussion to end entity certificates. Grids often > > use X.509 proxy certificates, so we want to allow certificate profiles > > derived from RFC 3280 (such as RFC 3820) if possible. > > I see, that's fine. I don't think specifying "v3" in the text implies anything w.r.t. end-entity vs. proxy certs, but removing it doesn't hurt either, if referencing RFC 3280 means v3. That's what it means to me, but perhaps more clarification is needed beyond what is already given in section 1. (?) > I had just wondered if your reason for removing was specifically to allow non-v3 certs. Definitely not. > BTW, in Section 7.2 [line 472] you've changed "end user certificate" to "end entity certificate", which might be confusing in light of your above explanation. Yes, upon reading that sentence again, perhaps that should just refer to a "certificate" without trying to qualify it further. I will change it. > But w.r.t. stability of drafts, my main concern is that AFAIK this profile was originally submitted to support a particular use case defined by certain US government agencies. As interoperability with these already existing deployments is likely to be a major driver of adoption of this profile, we should take care not to break interop with the original profile if at all possible. Frankly, I don't believe there are existing deployments of this profile. I don't know what "agencies" you're referring to, so I can only guess. BAH is involved with caBIG, so maybe caBIG is one of these "agencies". In any event, caBIG uses SAML V1.1. I'm not aware of any deployments based on this profile. > > > [lines 185-186] The way I read SAMLCore section 8.3.3, the > > > encoding rules for the DN actually differ from those in RFC > > > 2253, as defined by XML Signature, so the MUST and SHOULD > > > contradict each other here. I think we should simply > > > reference SAMLCore for the NameID Format rules, and not > > > repeat that material. > > > > I agree there is some confusion here. My understanding of what > > SAMLCore specifies via XMLSig (section 4.4.4) is the following: 1) the > > DN SHOULD conform to RFC 2253, and 2) there are special encoding rules > > applied to the DN. In other words, the encoding rules for the DN *do* > > differ from RFC 2253 but the underlying DN SHOULD conform to RFC 2253. > > In fact, I would like to make the latter a MUST. I think this needs > > to be clarified somehow and this spec seems like the right place to do > > it. > > I don't think there's any benefit to adding text here that serves no profile-specific purpose, but is merely intended to clarify a rule in SAMLCore. If SAMLCore needs clarification, we should enter it in SAML 2.0 Errata. Well, the problem with that is that the X509SubjectName URI was originally defined in V1.1, so if we make an entry in V2.0 Errata, what does that imply about use of X509SubjectName in V1.1? > Otherwise, we open the potential for divergence of interpretation of the SAMLCore requirements based on readings of these two specs. Yes, I think you are right. That normative language does not belong here. I will remove it. > At most, we should discuss this area of potential confusion in a non-normative section of this profile. That's a good idea. I'll do that. > > The reason this is important is that many grids rely on DN formats > > that do *not* conform to RFC 2253. These DNs do not interoperate in a > > non-grid environment and should not be allowed in this profile. > > Somehow we need to make that clear. I'm open to suggestion how the > > wording might change to achieve better understanding. > > This may be a genuine interop concern, but IMO the solution is not to indirectly exclude such DNs by tweaking the emphasis of the X509SubjectName format rules description, but to directly exclude them via language in the sections describing X.509 certificate authentication. Unfortunately, X.509 authentication is out of scope for this specification. Moreover, the format of the DN in the certificate is irrelevant. It is the string format of the DN in the XML that I'm concerned with. I dearly want this to be RFC 2253-compliant. > (It seems to me that the general intent of this profile is that the NameID used in the query should derive as directly as possible from the user's certificate, and not encourage manipulation to meet downstream formatting rules.) No, I disagree. Our implementation consumes Globus certificates (which use a legacy DN format), yet transmits RFC 2253-compliant DNs over the wire. There is good support for RFC 2253 in languages (such as Java), which is one reason why we want to use it. On the other hand, there is little (if any) support for the legacy DN format. This is why we're concerned that SAML underspecifies the format of X509SubjectName. > Are we sure, though, that this is a question that must be disposed of in the profile spec, rather than by agreement between participants in a given CoT? As far as I can see, this would be the only reason to upgrade RFC 2253 conformance from SHOULD to MUST in this profile -- is it necessary? Our experience suggests that RFC 2253 is a requirement, yes. We will not be able to interop with a deployment that uses some other format. Indeed, I don't see how to implement this profile without making that assumption. > > > [lines 360-450] I would hesitate to introduce new normative > > MUST requirements here that might break existing > > implementations' conformance with the profile spec. I think > > metadata usages should be RECOMMENDED, as in previous drafts, > > except insofar as the SAML 2.0 metadata spec already contains MUSTs. > > > > As stated on lines 327--329, metadata MAY be used and SAML 2.0 > > metadata is RECOMMENDED. If an entity chooses to use SAML 2.0 > > metadata, then (and only then) do the new MUSTs take effect. (I think > > this is the correct way to handle it, but I could be wrong.) I > > believe cd-02 is broken since it fails to include any relevant > > metadata bits. > > My concern with adding new requirements for metadata users is similar to my issue with using NameQualifier. It takes already existing SAML 2.0 IdPs -- that were originally just fine for interop using this profile, and that used metadata as per SAML 2.0 to describe their attribute responder capabilities -- and tells them the rules have changed and they need to be modified. I think we need to have a truly compelling reason before we contemplate such changes, and I'm not yet convinced that the benefits of the proposed schema extensions and MUSTs rise to that standard. First, I don't believe there are any deployments of this profile in existence today. Second, if there are, and they are using standard SAML V2.0 metadata, they are most assuredly broken. Schema extensions to both SP and IdP metadata are required for standalone attribute query. That's why Scott and I proposed a metadata extension for SPs, and why I'm proposing a metadata extension for IdPs. Without the latter, an SP would not know what endpoints support this profile. Let's not forget that the driving use case for this profile is an X.509 authentication-based SP. This use case leads to some interesting issues regarding name identifiers and metadata (as we have seen). There's no question existing deployments will have to be modified to participate in this profile. Tom Scavo NCSA/University of Illinois
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]