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

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

> > 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.
> 
> If that happens, didn't one of them screw up?
> 
> It's a serious question, I'm trying to understand DN theory 
> vs. practice.
> It's ok if the practice is that the theory is wrong, but 
> what's the point of
> a DN at all then? Why wouldn't I just leave the name entirely 
> nebulous, if I
> need issuer to make it unique.

If the theoretical ideal of a unitary global PKI were a reality, then having identical DNs assigned to two different entities would be a serious error. In practice, however, I imagine it's possible, albeit unlikely, that two uncoordinated CAs could do such a thing. Usage and deployment of PKI isn't quite like public Internet DNS or Ethernet MAC addresses at this point, where a collision will invariably cause the system to fail in some way -- particularly when it comes to end-entity certs issued to individual people.

The practical question for us is whether our profile should define a mechanism to address this probably rare error condition, or leave it as an operational issue to be resolved between the administrators of the domains in question in the event that it occurs within a single CoT. My vote goes to the latter.

> 
> > 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.
> 
> I would say that if you want to use NameQualifier, you should 
> define a new
> Format, because the existing Format left it unspecified. That's why we
> deprecated the use of the attribute for that Format. You'd 
> run the risk of
> expecting NameQualifier to be one thing and somebody having already
> implemented it to be something else.

Agreed. And I think that the benefit of defining a new Format here is not worth the cost in terms of making existing general-purpose SAML 2.0 IdP implementations ineligible to participate in this profile.

::Ari