RE: Basic Cert-2-Directory mapping question

["Slone, Skip" <skip.slone@xxxxxxxx>]

Oscar,

No offense taken, thus no apology needed. 

My comments from the soapbox last week were actually intended for the
community at large, and were meant to convey frustration at the apparent
unwillingness of solution providers in general to hear about -- and solve --
real world problems that are faced by users like myself in large, complex
environments.  

When I say "my environment is not so simple," the response I hear is "let's
not talk about the complexity; let's make some simplifying assumptions
instead."  

When I say "I have a nail AND a screw and need to put them both in the
wall," the response I hear is "we have provided you with a perfectly
adequate hammer, therefore you don't have a screw."

As I was using the nail/hammer analogy, dc-based names are the nails;
civil-attribute-based names are the screws. No matter how good a job my
company does of using nails and nails alone, we still have tens of thousands
of trading partners, many of whom prefer screws to nails and will continue
to use them indefinitely. Without a screwdriver, it's hard to do business
with them.

I don't really care what the screwdriver looks like.  I've suggested a
fairly simple design that I think will work. So far, no one has commented on
the design. What I've heard instead is a chorus of "we still don't like
screws."  Well, I don't like them either, but I still have to deal with
them.  If I'm simply overlooking a screwdriver that we have lying around
somewhere, I would appreciate someone pointing it out to me. 

 -- Skip 


-----Original Message-----
From: Oscar Jacobsson [mailto:oscar.jacobsson@xxxxxxxxxxx]
Sent: Thursday, January 11, 2001 5:16 PM
To: Slone, Skip
Cc: 'Sharon Boeyen'; ietf-pkix@xxxxxxx
Subject: RE: Basic Cert-2-Directory mapping question


> From: Slone, Skip [mailto:skip.slone@xxxxxxxx]
> 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."

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.

> And to quote someone Sharon and I both know, "If all you have is a hammer,
> 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