RE: [security-services] Groups -sstc-saml-x509-authn-attrib-profile-draft-10-diff.pdf uploaded

["Ari Kermaier" <ari.kermaier@oracle.com>]

Hi Tom,

Here are some replies to the discussion of proposed changes in this thread. I haven't had a chance to go through the collected threads that are not in draft-10.

> > [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. I had just wondered if your reason for removing was specifically to allow non-v3 certs. 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.

> > [line 170] While it is undoubtedly more correct to 
> > construct the Basic Mode URI from the new namespace URI 
> > you've introduced for the profile, I'm not sure we can make 
> > such a normative change at this point -- there are existing 
> > implementations/deployments to consider.
> 
> I didn't realize there was any guarantee of stability in a draft
> specification.  Regardless, this identifier isn't directly involved in
> the protocol so I'm not sure what could break in a prototype
> implementation based on this draft profile.

I'm not sure either if this could break something. I'll ask around. :-)

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.

> > [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. Otherwise, we open the potential for divergence of interpretation of the SAMLCore requirements based on readings of these two specs. At most, we should discuss this area of potential confusion in a non-normative section of this profile.

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

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?

> > [lines 188-189] If the NameID content DN is encoded as per 
> XML Signature (SAMLCore 8.3.3), but the NameQualifier value 
> DN is encoded as per RFC 2253, we might have a confusing situation.
> 
> Agreed.  The two DNs should have identical formats (whatever that
> turns out to be).
> 
> > Does anyone know what the originally proposed usage was for 
> this profile?
> 
> Document cd-02 did not specify NameQualifier at all, so this bullet is
> completely new.  I believe NameQualifier is needed to identify the
> cert issuer and guarantee uniqueness on the Subject DN.
> 
> There are three issues here: 1) Is NameQualifier needed to identify
> the issuer?, 2) Is NameQualifier needed to guarantee uniqueness of the
> Subject DN?, and 3) Is compatibility with previous versions of this
> document a goal?

These are good questions. My thoughts:

1) I don't know what the IdP/Attribute Authority can do with this information, as the fact that a the DN in the NameQualifier identifies an X.509 certificate's issuer isn't addressed in the processing rules for NameIDs in SAML, and this profile does not specify any additional processing rules either. (Nor should it, IMO.)

2) Use of a NameQualifier might be a good idea to guarantee uniqueness, since I guess two issuers could use the same DN to identify different principals. (Although it would probably be hard for a single SP to represent two such non-disjoint user spaces simultaneously.) However, SAMLCore [lines 474-475] says that the "NameQualifier and SPNameQUalifier attributes SHOULD be omitted unless the element or format explicitly defines their use and semantics", which the X509SubjectName format does not. Profiling by turning "MAY" into "SHOULD" or "MUST" is fine, but turning "SHOULD omit" into "SHOULD have" is probably asking for trouble.

3) The original CD for this profile pretty much allowed any general purpose SAML 2.0 attribute responder/IdP to participate in this profile, without implementing anything special. Changing that situation is no small thing, and would probably be a mistake w.r.t. real-world product implementations. (Also, as I've noted above, there are likely existing deployments, which served as the original impetus for this profile, that would be adversely affected.)

> I've already weighed in on the first two questions.  As far as
> backwards compatibility is concerned, there is no standard to be
> backwards compatible with.  Of course, breaking previous drafts should
> be avoided if possible, but I believe the document as it stands (i.e.,
> draft-10) lacks broad applicability.  The Basic Mode profile needs to
> be decomposed into smaller pieces that can be reused, something like
> this:
> 
> X.509 SAML Subject Profile
> SAML Assertion Profile for X.509 Subjects
> SAML Attribute Query Profile for X.509 Subjects
> 
> I have formulated such a decomposition for SAML V1.1 that I will
> upload to the document repository so you can see what I mean.  I think
> we ought to do something similar for SAML V2.0.

Maybe that would be a good thing, so long as we continue to have a higher-level profile that references those sub-profiles and results in the equivalient of this profile.

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

Best,
Ari