[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Basic Cert-2-Directory mapping question



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:oscar.jacobsson@xxxxxxxxxxx]
Sent: Thursday, January 11, 2001 11:39 AM
To: Slone, Skip
Cc: 'Sharon Boeyen'; ietf-pkix@xxxxxxx
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