OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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


On 8/4/06, Ari Kermaier <ari.kermaier@oracle.com> wrote:
>
> I've taken a stab at going through your proposed edits from draft-10-diff -- my thoughts are below.

Thanks for looking at this, Ari.

> Overall, this looks good, though I want to go through the metadata section and schema a little more carefully.

If something looks fishy with the metadata bits, that's because there
is. :-)  Scott and I had an offline discussion that exposed a
potential problem.  (I'll refrain from going into the details here.)
Consequently, the metadata section must be rewritten (or at least
reexamined).

> A question: Are there any comments/questions that you've posted to the mailing list (or that others have posted in response) that are not captured in this draft?

Yes, thanks for asking.

> If so, would you mind trying to cull them from the various threads into one place?

I already did that, I think.  See

http://www.oasis-open.org/archives/security-services/200607/msg00001.html

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

> [line 122] Why not call out the use-case descriptions as non-normative?

Agreed.

> [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 changed the URIs so that they fit into a larger framework.  The
original thought was to build off the Assertion Query/Request Profile
URI:

urn:oasis:names:tc:SAML:2.0:profiles:query

which basic mode extends, but I've since abandoned that idea.  In
another (related) document I'm writing, I employ the following URI
family:

urn:oasis:names:tc:SAML:1.1:profiles:X509:subject
urn:oasis:names:tc:SAML:1.1:profiles:X509:assertion
urn:oasis:names:tc:SAML:1.1:profiles:X509:query:attribute
urn:oasis:names:tc:SAML:1.1:profiles:X509:self-query:attribute

This allows for future expansion.  If, for example, a related set of
profiles were written for the emailAddress name identifier (or any
identifier for that matter), one could use the following stem:

urn:oasis:names:tc:SAML:1.1:profiles:email:*

If, on the other hand, we needed an authz decision query profile for
X.509 subjects, we could use

urn:oasis:names:tc:SAML:1.1:profiles:X509:query:authz

In this respect, even the URI in draft-10 is wrong.  It should be

urn:oasis:names:tc:SAML:2.0:profiles:X509:query:attribute:basic

or more simply

urn:oasis:names:tc:SAML:2.0:profiles:X509:query:attribute

since "basic" is implied.

N.B. Scott has said that "2.0" should not be used in such an URI, but
that's a problem.  How do I distinguish between SAML V1.1 and SAML
V2.0 in an otherwise identical URI?

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

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.

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

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.

> [lines 232-233] Same comment as for [line 170].

Same response.  The URI should be something like

urn:oasis:names:tc:SAML:2.0:profiles:X509:query:attribute:enhanced

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

> [lines 509-515] Again, we need to rationalize the subject DN formating issue between SAMLCore 8.3.3 and RFC 2253.

Yes, that is definitely needed.

Thanks,
Tom


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