Subject: Re: OCSP and LDAP

From: [email-masked] (Peter Gutmann)
Date: Wed, 8 Jan 2003 18:52:40 +1300

[email-masked] writes:

>some ten plus years ago i was at a acm sigmod conference and asked somebody
>what this x.500 stuff was ... and was told it is a bunch of networking types
>trying to re-invent 1960s database technology.

I've used that explanation too :-).  The conversion went something like this:

Other person: "Why is X.500 so special?  Why is no-one else doing this?"

Me: "Get your favourite book on database technology and look up 
     'Hierarchical databases'".

[Time passes]

Other person: "I looked in several books.  Many didn't mention it at all,
               and one had a half-page historical note saying it's something
               that was obsoleted by better technology more than two decades 
               ago".

Me: "Exactly".

Peter.

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 08 Jan 2003 12:01:44 -0800

>                that was obsoleted by better technology more than two decades

Heh.  Actually, hierarchical databases can be superlative to most all other 
technologies, when one has a static taxonomy to support.  Trying to 
represent (no less manage) a dynamically changing global namespace with 
scores of independent geopolitical naming authorities with a hierarchical 
database is rather ... ridiculous. :)

Cheers!  ____tony____

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 8 Jan 2003 21:58:56 +0100

>database is rather ... ridiculous. :)

Tony,
You are right!  You may be pleased to know that a remedy is in preparation
in the form of an I-D where the following extract addresses the situation mentioned.
/Anders

              Plug-and-Play Certificates for Web Services

1. Introduction and rationale

   To combine PKI with "Web Services" on a global scale presents a
   challenge, as it requires Relying Parties (RPs) to process signed
   messages possibly emanating from many different PKIs, while
   preferably using a unified RP PKI software- and user-interface.
   In the web-browser environment, global interoperability is only
   achieved due to the fact that web-server certificates supporting
   HTTPS [6], are based on a static ("hard-coded") profile [7],
   which is a prerequisite by browsers to correctly interpret such
   certificates.  To further simplify usage, most commercial CAs'
   root-certificates are already pre-installed in leading browsers.

   However, "Web Services" can unlike web-browsers, not depend on
   static PKI-schemes and pre-installed root-certificates, as this
   would severely limit the kind of entity-types and certificate-
   profiles that would be possible for RPs to accept.

   This specification introduces a CA-certificate-based, non-critical
   X.509 v3 extension, from now on referred to as a "PnP-descriptor",
   that works like an additional "specification" for associated End
   Entity (EE)-certificates.  The following introductory sections
   describe how this extension can support a more dynamic PKI-based
   ecosystem, by removing some major hurdles to wide-scale PKI usage.

1.1 Globally unique subject DNs

   The aforementioned Web-server certificates, contain globally unique
   subject Distinguished Names (DNs) [8] due to the fact that they
   certify Domain Name System (DNS) [9] host-names.

   However, for non-DNS-based entities, few existing certificate-
   profiles as well as RFC3280 [10] and RFC3039 [11] require subject
   DNs to be globally unique.  This may lead to possible name-clashes
   when multiple non-coordinated PKIs are to be handled by RPs.  One
   way to cope with this is to associate each CA-certificate with a
   unique "virtual" name-space.  This complicates CA-certificate
   renewals with respect to RPs, as well as making it more difficult to
   efficiently explore common certificate-profiles and associated
   naming-domains shared by multiple CAs (exemplified by many national
   ID-schemes), as both these scenarios require manual and error-prone
   RP configuration to work.  Requiring CAs to deploy globally unique
   subject DNs by for example adding Domain Components (DCs) [8] is
   likely to be less popular, as well as breaking some existing RP
   software.

   The PnP-descriptor therefore supports an explicit naming-domain in
   the form of a Universal Resource Identifier (URI) [12]. Due to the
   two-level naming structure, the PnP-descriptor provides global
   uniqueness to any existing or future non-empty subject DN scheme.
   Below is a figure, illustrating the two-level naming system.
             ____
            /    \
           |  CA  |<--- PnP Naming domain:
            \____/      http://www.sampleregistry.org/members
            /    \
           /      \
          |       _\__
          |      /    \
          |     |  EE  | CN=John Doe, serialNumber=43155, C=US
          |      \____/
          |
         _|__
        /    \
       |  EE  | CN=Marion Anderson, serialNumber=43566, C=US
        \____/

   That is, Marion's fully canonicalized name could be expressed like

       "http://www.sampleregistry.org/members" :
       "CN=Marion Anderson, serialNumber=43566, C=US"

   Note: Canonicalization syntax is outside of this specification as it
   is mostly a disadvantage to merge naming domain and subject DN in a
   real application.

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 08 Jan 2003 17:08:26 -0500

Well, you guys are all much smarter than I am.

I used to think I knew a lot about Directory, then I attended a
few meetings. I figured that since I was pretty clever in my
understanding of the abstract syntax and notation that I
probably had a major leg up. I figured that directory was
just another term for database.

I figured that by having implemented shttp and early ssl in C
and the first code ever (I think) to issue a v1 certificate at IBM,
that maybe I had a clue. Turns out that just about an hour in a
Directory meeting is enough to make your hat fit better.

Extremely smart people involved. And they're probably not
working on what most folks think they are.

Phil

Tony Bartoletti wrote:

> Heh.  Actually, hierarchical databases can be superlative to most all 
> other technologies, when one has a static taxonomy to support.  Trying 
> to represent (no less manage) a dynamically changing global namespace 
> with scores of independent geopolitical naming authorities with a 
> hierarchical database is rather ... ridiculous. :)
>
> Cheers!  ____tony____
>
>