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

["Tom Scavo" <trscavo@gmail.com>]

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