[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCSP and LDAP
>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. :)
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
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.