Subject: "Basic" path-validation question

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Jan 2003 09:16:23 +0100

Hi,
Below we have a little scheme where an RP have
"accepted" CA1 by "installing" the RootCA and CA1
in the trust-store:

     /CA1->EE_type1 (class 3 id)
RootCA-CA2->EE_type2 (low assurance e-mail)
     \CA3->EE_type3 (web-server-cert)

Now, the RP receives a message containing a path
of CA3 + EE_type3.

What should a conforming path-validation say about this?

Or is this (as I suspect) up to the implementation to have
an opinion about?

cheers,
Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 17 Jan 2003 12:55:33 +0100 (CET)

In message <007501c2be00$bb24be20$0500a8c0@arport> on Fri, 17 Jan 2003 09:16:23 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Below we have a little scheme where an RP have
anders.rundgren> "accepted" CA1 by "installing" the RootCA and CA1
anders.rundgren> in the trust-store:
anders.rundgren> 
anders.rundgren>      /CA1->EE_type1 (class 3 id)
anders.rundgren> RootCA-CA2->EE_type2 (low assurance e-mail)
anders.rundgren>      \CA3->EE_type3 (web-server-cert)
anders.rundgren> 
anders.rundgren> Now, the RP receives a message containing a path
anders.rundgren> of CA3 + EE_type3.
anders.rundgren> 
anders.rundgren> What should a conforming path-validation say about this?

Since the RP already has RootCA in it's store, and supposedly trusts
it, and it verifies CA3 which in turn verifies EE_type3, the path is
validated.  No problemo.  Or did I miss something?

This is under the assumption that it doesn't matter how the RP gets
the certificates it gets hold of in the process of messages, as long
as there's a chain that validates back to a trust point (in the case,
RootCA).

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Jan 2003 13:22:16 +0100

>validated.  No problemo.  Or did I miss something?

Nema problema.  Except for the fact that the RP probably only agreed
to accept class 3 id's and now got fooled by the path-validation.

Isn't this what we engineers call "broken" eh?

<snip>

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 17 Jan 2003 13:26:48 +0100 (CET)

In message <011001c2be23$22209a50$0500a8c0@arport> on Fri, 17 Jan 2003 13:22:16 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >> Below we have a little scheme where an RP have
anders.rundgren> >> "accepted" CA1 by "installing" the RootCA and CA1
anders.rundgren> >> in the trust-store:
anders.rundgren> >> 
anders.rundgren> >>      /CA1->EE_type1 (class 3 id)
anders.rundgren> >> RootCA-CA2->EE_type2 (low assurance e-mail)
anders.rundgren> >>      \CA3->EE_type3 (web-server-cert)
anders.rundgren> >> 
anders.rundgren> >> Now, the RP receives a message containing a path
anders.rundgren> >> of CA3 + EE_type3.
anders.rundgren> >> 
anders.rundgren> >> What should a conforming path-validation say about this?
anders.rundgren> 
anders.rundgren> >Since the RP already has RootCA in it's store, and
anders.rundgren> >supposedly trusts it, and it verifies CA3 which in
anders.rundgren> >turn verifies EE_type3, the path is validated.  No
anders.rundgren> >problemo.  Or did I miss something?
anders.rundgren> 
anders.rundgren> Nema problema.  Except for the fact that the RP
anders.rundgren> probably only agreed to accept class 3 id's and now
anders.rundgren> got fooled by the path-validation.
anders.rundgren> 
anders.rundgren> Isn't this what we engineers call "broken" eh?

In that case, either the policy extensions in some certificate or the
path validation software is broken.  The only way to know if a
certificate is "class 3" is the policy extension and the knowledge of
what policy OIDs corresponds to "class 3".  The software should be
configurable with a set of acceptable policy OIDs, and should verify
that policy is properly maintained in the whole path.

If the RP only accepts class 3 id's, then it should invalidate that
path just by looking at the EE_type3 certificate.

Note: there's a lot of software out there that doesn't process the
policy checks, either at all or badly...

Have you looked at RFC3280?  It has a pretty good description of what
to check and how during validation.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 17 Jan 2003 14:38:46 +0100

Anders Rundgren a dit :

 > [...]

>Isn't this what we engineers call "broken" eh?
What is broken is the application, if it *requires* to install both 
RootCA and CA1 in order to trust EE_type1.

It should be possible to install only CA1 as a trust anchor, there is no 
requirement in the path-validation that the trust anchor be self-signed.

If the application is OpenSSL, you were talking with someone who is 
supposed to be able to do something about it :-)

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Jan 2003 15:55:34 +0100

Jean-Marc,

>RootCA and CA1 in order to trust EE_type1.

Ahh, you "solved" the problem by disconnecting the CAs.
But that is an entirely different scenario.

>requirement in the path-validation that the trust anchor be self-signed.

Although possible, this will make CA1 renewals require reinstallation
which it does not necessarily require if it is connected to a higher-level
root.  If this "automation" is outside of RFC3280 is though outside of my
knowledge.

>supposed to be able to do something about it :-)

I'm more in thinking in terms of RFC-level handling.

Rickard: I can hardly see that policy-extensions would solve this
without moving the problem into "app-space".  E.g. "Class 3"
is one CAs way of expressing things,  "Premium grade" is
another likely form. 

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 17 Jan 2003 22:49:17 +0100 (CET)

In message <[email-masked]> on Fri, 17 Jan 2003 14:38:46 +0100, Jean-Marc Desperrier <[email-masked]> said:

jean-marc.desperrier> What is broken is the application, if it
jean-marc.desperrier> *requires* to install both RootCA and CA1 in
jean-marc.desperrier> order to trust EE_type1.

Yet, most software do that, *or* install just RootCA and expect to get
every intermediate CA certificate along with the messages sent to it
(that happens with S/MIME, and many SSL-enabled servers present a
whole chain except for the root itself).  From a purely PKI point of
view, both methods are broken, all needed certificates should be
retrievable from one or several publically available stores...

jean-marc.desperrier> It should be possible to install only CA1 as a
jean-marc.desperrier> trust anchor, there is no requirement in the
jean-marc.desperrier> path-validation that the trust anchor be
jean-marc.desperrier> self-signed.

Actually, I've heard quite different opinions on that.  Some people
assume that the trust anchors are self-signed.  I see no real problem
with that kind of thinking...  If nothing else, you can always set up
your own small CA, certify any other CA you trust with your CA's key,
and have your CA as trust anchor...

jean-marc.desperrier> If the application is OpenSSL, you were talking
jean-marc.desperrier> with someone who is supposed to be able to do
jean-marc.desperrier> something about it :-)

I've certain plans in this area for OpenSSL.  I hope to have most of
it ready for 0.9.8.  As it is right now, it has rather crappy
verification routines, as well as the lookup of certificates (it's
in-memory, and lacks of certain needed features).  No policy checking
(as far as I've been able to see and test), and no support for trees
of certificate chains (i.e. it doesn't support the possibility for any
specific subject to have more than one valid certificate at a time...

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 17 Jan 2003 23:03:11 +0100 (CET)

In message <001901c2be38$99928e80$0500a8c0@arport> on Fri, 17 Jan 2003 15:55:34 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Jean-Marc,
anders.rundgren> 
anders.rundgren> >It should be possible to install only CA1 as a trust
anders.rundgren> >anchor, there is no requirement in the
anders.rundgren> >path-validation that the trust anchor be
anders.rundgren> >self-signed. 
anders.rundgren> 
anders.rundgren> Although possible, this will make CA1 renewals
anders.rundgren> require reinstallation which it does not necessarily
anders.rundgren> require if it is connected to a higher-level root.

A very valid point which is often forgotten.

anders.rundgren> If this "automation" is outside of RFC3280 is though
anders.rundgren> outside of my knowledge.

RFC3280 says nothing on how you get hold of the certificates you use
for validation, so yes, it's outside the scope of that RFC (unless
I've done a miserable job reading it).

anders.rundgren> Rickard: I can hardly see that policy-extensions
anders.rundgren> would solve this without moving the problem into
anders.rundgren> "app-space".  E.g. "Class 3" is one CAs way of
anders.rundgren> expressing things,  "Premium grade" is another likely
anders.rundgren> form.

Actually, the problem goes one step further; it goes to the user or
the local admin.  A trust can't be decided upon by the application or
by the PKI library you use, or even by the OS.  It has to go back to
the user (or admin), and the user (or admin) has to decide where to
put his or her trust.  The way I udnerstand PKI, trust is ultimately
placed upon policies and trust anchors that implement those policies.
What is called "Class 3" is really a question of the policy attached
to those certificates.  The same thing goes for "Premium grade".  Are
those two supposed to be the same?  How would you know that unless you
read the policies they are the names for?

I might some day define a policy that I call "Class 3".  Will that be
the same as what you call "Class 3"?  I have strong doubts about that.

Just out of curiosity, what exactly were you thinking of doing?  Some
kind of automatic parse of some name somewhere into which you would
put some level of trust?  Or were you going to define some kind of
standard extension that would express something called "Class 3" and
decide for everyone exactly what that means?  Or something else?

What is really needed is to have a standard PKI library that supports
some kind of configuration at user and admin level, that would define
exactly what trust the user or admin places in different policies and
trust anchors.  If all applications use that same library, that trust
configuration would apply on all those applications.

Hmm, I'm getting ideas for OpenSSL here...

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 18 Jan 2003 10:26:51 +0100

Richard,

<snip>

>> If this "automation" is outside of RFC3280 is though
>> outside of my knowledge.

>RFC3280 says nothing on how you get hold of the certificates
>you use for validation, so yes, it's outside the scope of that
>RFC (unless I've done a miserable job reading it).

I think you have done a good job reading it, which means that my
"basic" question apparently is completely outside of the realm of
PKIX-standards.  Close to UNBELIEVABLE  IMNSHO.

>> Rickard: I can hardly see that policy-extensions
>> would solve this without moving the problem into
>> "app-space".  E.g. "Class 3" is one CAs way of
>> expressing things,  "Premium grade" is another likely
>> form.

>read the policies they are the names for?

You seem to have the answers already :-)  Mines are identical...

>the same as what you call "Class 3"?  I have strong doubts about that.

Me too.

>decide for everyone exactly what that means?  Or something else?

Well, the PnP PKI specification which I sent to you is an indication
of what I'm looking for.  However, I don't have much faith in the
policy-mechanism as the foundation for "automation", I rather see
that a trust-administrator (not a user) surfs to SuckerTrust's
web-site and after reading some 10 lines or so, clicks on the link
that starts downloading the path for the SuckerTrust "Premimum ID".

>configuration would apply on all those applications.

I agree but I want to extend this to the realm of standard if possible.

>Hmm, I'm getting ideas for OpenSSL here...

Input is always appreciated!

The only REAL alternative to improvements in the area of trust 
administration is IMHO that we forget about the whole issue and
starts to rely on a very limited set of TTP issuers whos roots
are pre-installed by software vendors.

If the requirement is that users must understand PKI to use it,
PKI will never work on a mojor scale.  Users should not even
have to know what a PKI is!!!  "Trust-administrators" may know
just a little bit more...

cheers
Anders

---

From: Camile Howe <[email-masked]>
Date: Sat, 18 Jan 2003 15:36:58 -0800 (PST)

Design "faith" to support a policy-mechanism to permit
automation...

<<<excerpt> of a Anders/Richard snip>>>
> that starts downloading the path for the SuckerTrust

anders - Believe that this above referenced,
"admin-reliant" approach would preclude
wide-usage/acceptance since it sounds too admin
maintenance intensive...This thread sounds like we're
relying heavily on a "admin in the middle"...as
default, rather than the exception? 
 "trust-administrator (not a user) surfs to
SuckerTrust's web-site" should be an exception
required when a "new" vendor ID comes out ... I can't
perceive (large-scale company) Admins expending the
"implied" maintenance time on adding "trusted
IDs/certs".  e.g. Our company (165,000 nodes plus)
relies heavily on centralized management and would
expect our forum to come up with "centralized and
automation approach" that reduces administrator time
and potential errors (this has potential to get to the
core of securing network).    

elieve a PKI standard library with automation built-in
has to be the goal.  Sure...I agree it ultimately gets
down to an admin making the decision as to what the
applications/PKI standard library references, but
surely this is done from a centralized location such a
file referenced by the applications/PKI library API
(API supports the policy-mechanism for apps to
automate), so the admin pre-configures these upfront
and adds to this repository as required.  
If we look towards (allow for) a design of this type
then the "automated decision" can be embedded in the
applications deployed... believe we can gain
industry-wide support and usage... 
From the cadre of business/industry forums I
follow.....Suspect that shortly the future holds ...
web-centric (CD distribution) centralized management
of "registered" companies so admins can go to a common
place where they know the IDs are in fact,
pre-screened, registered and validated vendor IDs they
can download on a large scale, rather than doing one
at at a time.

Or am I mis-understanding the "intended"
implementation?

Camile

> just a little bit more...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Sun, 19 Jan 2003 20:39:48 +0100

>PKIX-standards.  Close to UNBELIEVABLE  IMNSHO.
Very believable, because your question is not basic.

The premice on which you start is that the organisation can not be 
tailored to easier what you want to do, and that they will not be an 
application level input restricting which kind of certificate you want 
to trust. It's no so surprising you end up with no solution.

What you started with was distributing a root CA and one of its sub-CA.
This mean you prived two trust anchors, and they are added to each 
other, the second can not somehow restrict the application of the first.
In fact, as the root CA includes all the domain of the sub-CA, it was 
not necessary to provide the sub-CA.
If you don't want to trust everything the root signs, then *don't* 
distribute the root, or you MUST  use a higher level mechanism to 
restrict what is trusted.
This is the way X509 PKI works, and it has the definitive advantage of 
being simple !

If it was needed to distribute the subCA in addition to the root, 
because the clients don't always provide the full path to the root, then 
when the subCA is replaced, the clients will still not provide the full 
path, so you will *need* to distribute the new sub-CA.

So you won nothing by distributing the root.
If you want to trust only the domain of the subCA, then only distribute 
the sub-CA.

If you want to be able to renew easily the sub-CA, then one solution can 
be to create an intermediate CA between the root and the current sub, 
that only signs the sub-CA you want to trust.
This is what I meant by tailoring the organisation to easier what you 
want to do.

But in fact your true question is how to distribute easily new trust 
anchors, and this is not part of RFC3280.

I've seen some people seriously try to find an answer to this, they came 
up with the following kind of solutions, and I don't really see another 
way to do it :
- Have in the application one special trusted certificat that signs a 
list of the CA that are part of your trust anchors in the RFC3280 
meaning, and then a distribution channel to distribute new versions of 
that signed message.

You can use a SET-like chain mechanism to be able to regularly renew 
that special certificate.

Describing that kind of mechanism could make a very valid informational 
RFC :-).

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 20 Jan 2003 09:52:37 +0100

Jean-Marc,

(text deleted)

> anchors, and this is not part of RFC3280.

This is part of RFC 2510 PKI Certificate Management Protocols.
See section 2.4 "Root CA key update".

> Describing that kind of mechanism could make a very valid informational 

RFC 2510 is Standards Track.

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 20 Jan 2003 11:33:35 +0100

Jean-Marc,
I understand what you are saying and I don't disagree with
it either.  May I put some other associated questions?

The point of having a root-certificate according to the sketch I
posted, should be that the root is supposed to be long-lived (using
a longer key maybe) compared to sub-CAs which should make
sub-CA renewals somewhat easier (?) for RPs to handle.  Right?

Or is the only really valid argument for have a root like the one
shown, is that multiple more or less independent CAs can be
"trusted" with just one RP "install" procedure.

To make this somewhat clearer: I'm plotting with a scheme (I-D),
where a trust administrator must explicitly "accept" a CA that
has a "trust-store" mark as a part of an extension mechanism.
The extension mechanism also manages name-spaces,  by adding a
new dimension (and control) to the name-space embraced by EEs,
allowing either "Sharing" or "Galvanic isolation" between CAs.

Cheers,
Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Mon, 20 Jan 2003 14:52:43 +0100 (CET)

In message <002101c2c06f$676facb0$0500a8c0@arport> on Mon, 20 Jan 2003 11:33:35 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> The point of having a root-certificate according to the sketch I
anders.rundgren> posted, should be that the root is supposed to be long-lived (using
anders.rundgren> a longer key maybe) compared to sub-CAs which should make
anders.rundgren> sub-CA renewals somewhat easier (?) for RPs to handle.  Right?

Usually, the point of installing any CA certificate is that one would
trust it and the hierachy below it...

anders.rundgren> Or is the only really valid argument for have a root like the one
anders.rundgren> shown, is that multiple more or less independent CAs can be
anders.rundgren> "trusted" with just one RP "install" procedure.

It wasn't apparent that the diagram you showed was of more or less
independent CAs.  It could as well have been a hierarchy that you can
trust as a single entity (as long as you can verify a path from an EE
cert back to the root).

So, it sounds like you have a number of independent CAs, and you want
them to be under some kind of umbrella structure.  I believe that most
PKI people would call that "cross-certification", and that the root is
another independent CA that has expressed trust in the CAs you want to
have under that umbrella by cross-certifying (possibly just one-way,
is there a more proper term for that?), with policy mappings to
express the kind of trust to put into each of those CAs.  And in that
case, it's perfectly valid to have the root as trust anchor.

Did I understand what you said correctly?

anders.rundgren> To make this somewhat clearer: I'm plotting with a scheme (I-D),
anders.rundgren> where a trust administrator must explicitly "accept" a CA that
anders.rundgren> has a "trust-store" mark as a part of an extension mechanism.
anders.rundgren> The extension mechanism also manages name-spaces,  by adding a
anders.rundgren> new dimension (and control) to the name-space embraced by EEs,
anders.rundgren> allowing either "Sharing" or "Galvanic isolation" between CAs.

That sounds just like reinventing policies and name constraints.  I
can only see confusion out of that, since people will then wonder what
to use, if one should use differemt mechanism in different domains,
and what happens if both mechanisms to do the same thing are used in
the same certificate.  I fear it will just send X.509 and the
corresponding RFCs down the path of uselessness...

Then again, perhaps I misunderstand what you're after...

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 20 Jan 2003 16:22:30 +0100

Richard,

>trust it and the hierarchy below it...

Sure, but that does not answer the question I put.  I.e. the "value"
of a root-subCA arrangement.

<snip>

>Did I understand what you said correctly?

Well, the intention was just a single CA-hierarchy

>That sounds just like reinventing policies and name constraints.

No, policies and name-constraints work _within_ a CA (hierachy).

This name-space-thing is _between_fully_ idependent CAs that
do not even know the others' existance.  This allows a "good"
CA to be protected from a "bad" CA infringing on the good CA's
name-space.  Why would anybody accept a "bad" CA? Well:
- How can you have any opnion about a company CA on the
  other side of the globe?
- Do you have any option but to accept their credentials if you
  are going to do business with them?

<PolicyExtensionRant>
In the type of scenario mentioned above I don't see much use of
policy-extensions as they cannot be verified, and in local scenarios,
policy should already be "implicit", "known" etc.  which in my
opinion renders this a "rather" overrated mechanism.  A quick look
on my Thawt web-server path also indicated the total absence of any
"policyjunk"-extensions.
</PolicyExtensionRant>

>I can only see confusion out of that, since people will then wonder what

The "intent" is rather to send the de-funct X.500 global naming-system
where it belongs, acknowledged by a quite a few people of this list...
The mechanism works as an additional layer on top of RFC3280.

>Then again, perhaps I misunderstand what you're after...

To some extent yes.  But, e-mail has its limitations and PKI
is very complex.

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Mon, 20 Jan 2003 16:52:53 +0100 (CET)

In message <000e01c2c097$bf53cc90$0500a8c0@arport> on Mon, 20 Jan 2003 16:22:30 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> >Did I understand what you said correctly?
anders.rundgren> 
anders.rundgren> Well, the intention was just a single CA-hierarchy

OK.

anders.rundgren> >That sounds just like reinventing policies and name
anders.rundgren> >constraints. 
anders.rundgren> 
anders.rundgren> No, policies and name-constraints work _within_ a CA
anders.rundgren> (hierachy).

I'd like to argue that (eh, the implication that it only works within
a hierarchy), but I recognise that it takes some work (i.e. a bit of
reading through long documents with varied legal status).

anders.rundgren> This name-space-thing is _between_fully_ idependent
anders.rundgren> CAs that do not even know the others' existance.
anders.rundgren> This allows a "good" CA to be protected from a "bad"
anders.rundgren> CA infringing on the good CA's name-space.

If I do what I'd ideally like to do, using my own small CA (which,
contrary to what some seem to think, is not the same as a bridge CA,
at least as far as I understand them) to certify, for my own purposes
only, other CAs, then in each such certification, I can also say that
I only accept certificates signed by them within specific name trees.
That's one way to use name constraints.

I realise that what I would do isn't something the average user would
do.  In effect, the way root CAs are handled in browsers today is an
expression of complete trust, by having no restrictions whatsoever in
the hierarchy below them.

Let me ask you, exactly where would that name-space extension be?

anders.rundgren> Why would anybody accept a "bad" CA? Well:
anders.rundgren> - How can you have any opnion about a company CA on
anders.rundgren>   the other side of the globe?

Depends.  Do I do business with them?  Then I believe that I will
sooner or later get to know them to a certain part.

anders.rundgren> - Do you have any option but to accept their
anders.rundgren>   credentials if you are going to do business with
anders.rundgren>   them?

Perhaps not.  Also, I might have several levels of acceptance, or to
get back to that, trust.  If we're talking about certification (which
I assume we are), I trust they are running a CA for their own
purposes, or this point is moot.  If they do, what stops me from
signing a certificate for their CA, while expressing very little
trust, through policy mappings for example.

anders.rundgren> <PolicyExtensionRant>
anders.rundgren> In the type of scenario mentioned above I don't see
anders.rundgren> much use of policy-extensions as they cannot be
anders.rundgren> verified, and in local scenarios, policy should
anders.rundgren> already be "implicit", "known" etc.  which in my
anders.rundgren> opinion renders this a "rather" overrated mechanism.
anders.rundgren> A quick look on my Thawt web-server path also
anders.rundgren> indicated the total absence of any "policyjunk"-
anders.rundgren> extensions.
anders.rundgren> </PolicyExtensionRant>

Sure, Thawte has no policies.  From where I stand, that means they
trust anything (like having an anyPolicy policy in the certificate).

Now, granted, there seems to be no way, today, to express in popular
software what restrictions you want to put on different CAs, either
policy-wise or name-wise (or in any other way).  The only way that I
know is to do what I'm going to, have your own CA, and do one-way
certification with all the restrictions or freedoms that you'd like.

anders.rundgren> The "intent" is rather to send the de-funct X.500
anders.rundgren> global naming-system where it belongs, acknowledged
anders.rundgren> by a quite a few people of this list...
anders.rundgren> The mechanism works as an additional layer on top of
anders.rundgren> RFC3280.

Well, in that case, you're going away from X.509 rather sharply.
Perhaps it would be better to look at something else, rather than
further obfuscating something that seems to be obfuscated for a large
number of people already?  Then again, that wouldn't work with today's
software...

No offence meant, BTW...

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 20 Jan 2003 18:11:13 +0100

Richard,

<snip>
>> The "intent" is rather to send the de-funct X.500
>> global naming-system where it belongs, acknowledged
>> by a quite a few people of this list...

>Well, in that case, you're going away from X.509 rather sharply.

Hum, ISO have had 15 years to establish a working global registry...
After a while, ISO gave in and added DCs based on DNS. 
Still this is both a very little used "feature" in certificates, as well as
a de-facto non-standard solution, as URIs are used as identifiers by
the rest of the IT-industry.

In the meantime [more or less] local name-spaces have been
successfully established.  The Swedish ID-certificate is an example.
I doubt that they will change that into using DCs.  Using the proposed
mechanism they will never have to either as it augments certificates
with a global URI name-space [for those situations which need it].

So the question really boils down to: How is PKI going to achieve a
global name-space based on DNS [=the only working naming-system]?
That there are "standards" for that is no guarantee for this to happen IMO.
Life is complicated :-|

<snip>

Anders