Subject: Re: Single canonical names

From: Martin Rex <[email-masked]>
Date: Thu, 4 Nov 2004 22:06:46 +0100 (MET)

Nicolas Williams wrote:
> 
> On Mon, Oct 25, 2004 at 02:53:16PM -0400, Sam Hartman wrote:
> > To be useful you need to standardize which name you pick as the
> > canonical name from a cert.
> 
> For a given query form.

Which part is insufficient, you need to specify much more ...

consider the following existing variants:

1.  /C=US/OU=org2/OU=org1/O=Foo, Inc./CN=John Doe
2.  C=US, OU=org2, OU=org1, O="Foo, Inc.", CN=John Doe
3.  cn=John Doe, o="Foo, Inc.", ou=org1, ou=org2, c=US
4.  CN=John Doe, O="Foo, Inc.", OU=org1, OU=org2, C=US
5.  CN=John Doe, O="Foo, Inc.", OU=org2, OU=org1, C=US

Whether 4. and 5. should be considered equivalent is the most
interesting question.  There are very few (if any) products that
will apply a sorting order to RDNs (and those that do, what
might be the result when those compare 4. and 5.?). 

Just look at SPKM (rfc2025).  The spec is hardly sufficient to
come up with useful wire-interoperable implementations, but
the lack of a standardized name format makes is quite useless as
a standard because it will not fly in a heterogeneous distributed
environment.

I know several independent implementations of rfc-2025, and neither
two are fully interoperable on names.

But actually there appear to be more proprietary variants that are loosely
based on rfc-2025 than there are true rfc-2025 implementations.  Still,
no two products that I've encountered are fully interoperable on names.

There's limited interoperability on the printable INput, and zero
interoperability on the binary canonical form.  In this respect,
the rfc1964 gssapi mechanism is magnitudes better, as it defines
the canonical encoding and a mandatory printable representation.

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 Nov 2004 21:45:25 +0100 (MET)

(I'm a little behind on my Email...)

> canonical name from a cert.

I believe it is possible to come up with a single standard about
name mapping for X.509 certs.  X.509 is magnitudes to "flexible"
and Companies are magnitudes to "creative" when setting up
PKIs and their own CAs, including a lot of fancy information
in the DNs that just make life harder for software and admins
which are being faced with those names through APIs for secure
authentication...

The best thing would be to have it configurable for the software
which components are used to make up a distinct name at the
authentication API -- however that creates the problem of how
one creates a homogeneous installation with the same configuration...

(Having a single standard which can be preconfigured/hardcoded
makes software maintenance&distribution so much easier).

>
> Also, the compatibility issue is not just about whether you have
> something to return.  The issue also includes the question of whether
> a gssapi v2 application that uses gss_export_name as intended by the
> v2 spec will get the desired behavior.
> 
> If you pick some arbitrary mapping then you may have an implementable
> protocol but you will not have a protocol that meets users' needs.

You underestimate the "creativity" of customers.  A while ago I had
a customer asking why our software didn't include their particular
altSubjectName extension in the ACLs for authentication with
SSL client certs in our software.  He indicated that his CA might
issue distinct certs that would only differ in the contents of
their special altSubjectName extension and not in the contents
of the DN itself.

Well, I had to explain him that I'm sorry, but we wouldn't support
that, and I suggested that they better fix their CA, because there
are certificate profiles (like rfc2459) which clearly state that
a CA issuing certs with non-empty subjectDNs must issue unique
subjectDNs for certs identifying distict end entities.

-Martin