Subject: RE: Basic Cert-2-Directory mapping question

From: "Slone, Skip" <[email-masked]>
Date: Thu, 11 Jan 2001 13:29:28 -0500

In response to this, I'm inclined to join Sharon on Marshall's soapbox and
echo her words:

"... I believe a more constructive approach is to accept the fact that
different parts of the world and different environments will use a variety
of nameforms ... We are not the global naming police either and should not
try to impose the rules that anyone uses to name entities to which they
issue certificates."

And to quote someone Sharon and I both know, "If all you have is a hammer,
every problem looks like a nail."

 -- Skip

-----Original Message-----
From: Oscar Jacobsson [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 11:39 AM
To: Slone, Skip
Cc: 'Sharon Boeyen'; [email-masked]
Subject: Re: Basic Cert-2-Directory mapping question

"Slone, Skip" wrote:
> I would just like to add that, in addition to X.521 and some LDAP
> specs, the ability to recognize civil naming attributes in the issuer
> and subject fields of an X.509v3 cert is mandated in RFC 2459 (ref
> section 4.1.2.4) and in son-of-2459.  

True, and I don't think "recognizing" them as certificates is the issue
here. More on this as we get to your proposed requirement.

> In terms of a requirement for this WG, as I see it, we have a
> requirement to be able to find the associated repository for any
> validly constructed PKIX-compliant certificate.

I would prefer this requirement restricted to apply only to those
certificates that were consciously created for deployment on the
Internet.

Come to think of it, maybe this would be better off split into two
separate discussions. One on creating/endorsing/applying a naming scheme
that will allow us to deploy PKIs over the Internet, for which I'd say
that repository discovery would be a must, and another on handling the
"legacy" (as in non-Internet based) X.521-style certificates already in
use, probably most importantly those shipped along with our web
browsers.

> I'm open to suggestions on HOW to resolve these domain-amiguous
> certs.

The problem here is in their very ambiguity. The subjects of these
certificates are not necessarily directory entries in the first place. I
know I've personally held a sizeable amount of certificates, the
subjects _and_ issuers of which have been completely fictitious. Or
maybe not fictitious, but completely arbitrary anyway. Of all the
certificates ever issued to me, no two have ever used the same DN.

Regards,

//oscar

---

From: "Oscar Jacobsson" <[email-masked]>
Date: Thu, 11 Jan 2001 23:16:05 +0100

> From: Slone, Skip [mailto:[email-masked]]

I'm sorry if I came across as clamouring for rules be imposed. I know that this working group has a tendency to be wary of suggestions that don't cater for distinguished names containing cat MPEGs, so I should probably have been more careful. The requirements I suggested were for a possible naming standards document, conformance to which need not be enforced.

The case at hand is not, IMHO, one of dictating that "all distinguished names must be according to our will, or you shall feel our wrath". A document however, outlining a naming strategy that would require of the users of certificates named accordingly no a-priori knowledge of their issuer (save for eventually having to reach something explicitly trusted in the chain) in order to perform path validation, is something I would personally consider very valuable indeed. I'm reasonably confident that organizations intending to act as certification authorities or trusted third parties would agree.

> every problem looks like a nail."

It seems I was less than clear here as well. :-(

My intention was to point out that there are actually two separate problems here (one nail, if you will, and one screw) each looking for its own solution:

1. Defining a repository, and subsequently entry, discovery process for arbitrarily named entries.

2. Defining a naming scheme that _if applied_ would automate this repository and entry discovery process.

I am only trying to address the second of these problems. The first is only an issue because nobody seems to have properly addressed the second before deploying certificates on the Internet en masse. The further we wait before addressing number two, the more of a problem number one will become.

I should probably make a habit of pointing out that the opinions stated here are my very own, and not necessarily those of my employer.

Cheers,

//oscar