Subject: Adding Metadata to PKI = ERROR?

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 5 Feb 2004 08:41:01 +0100

Dear List,

Metadata (data about data) is an intrinsic part of many information
resources like relational databases, file systems and various
proprietary systems.  The main utility of metadata is to support
administration and development processes.

However, the PKI community has so far resisted (or neglected)
this possibility and mainly relies on out-of-band distributed
information like certificate policy documents, which essentially
is "manual" metadata.

According to some PKI people, putting something like a subset
or parameterized CP doc in a self-signed CA certificate using an
X.509.v3 non-critical extension, violates the very core of PKI and
X.509, as the CA cannot vouch for itself.

Isn't that what a CP doc does today but without using cryptographic
bindings?

In my opinion such an extension is principally no different than
CAs having Subject DNs like "CN="TrustUS High-value CA".

Any opinions on this?

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 05 Feb 2004 10:54:33 +0100 (CET)

Dear Anders,

I must honestly say that I'm not entirely sure why having CP and CPS
pointers in a self-signed cert would be such a big deal.  They would
be completely ignored by the path validation as shown in RFC3280 (at
least as far as I understand the algorithm), but would be informative.

However, there's a different thing we touch here, and it's entirely
non-technical: trust.  And this is something that was learned more or
less by everyone back when PGP came to this world if not earlier.  You
simply can't (well, actually, you can if you want to, but then I'll
call you a fool) put any trust in a bunch of bits that you received
from the Gods know where, no matter what more or less fancy documents
come with it.

To get back to how things work out with PGP, you normally verify the
fingerprint of the key you received by talking to the owner of said
key and often checking that the person is really who he or she is (ID
check or something similar) before you put any trust in that key.
Trusting a CA certificate SHOULD be no different.  The work is to call
the people responsible for a CA, check the fingerprint and verify with
those people that the CA is really what it pretends to be (and if
you're paranoid, you will *maybe* decide to trust them :-)).

If the unknown CA has a cert signed by someone else that you trust,
the matter is often different, but then, you don't have the unknown CA
as a trust point anyway, do you?

If I found a self-signed CA certificate with CP and CPS pointers in
it, I would regard it as possibly useful information, but if I did the
work properly (which I'll admit I don't very often, yet :-/), I would
still have to get in touch with the responsible people, make sure they
identify themselves and the CA cert properly, and request that they
send me copies of their CP and CPS.

In message <006c01c3ebbb$7268d330$0500a8c0@arport> on Thu, 5 Feb 2004 08:41:01 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Metadata (data about data) is an intrinsic part of
anders.rundgren> many information resources like relational databases,
anders.rundgren> file systems and various proprietary systems.  The
anders.rundgren> main utility of metadata is to support administration
anders.rundgren> and development processes.
anders.rundgren> 
anders.rundgren> However, the PKI community has so far resisted (or
anders.rundgren> neglected) this possibility and mainly relies on
anders.rundgren> out-of-band distributed information like certificate
anders.rundgren> policy documents, which essentially is "manual"
anders.rundgren> metadata.
anders.rundgren> 
anders.rundgren> According to some PKI people, putting something like
anders.rundgren> a subset or parameterized CP doc in a self-signed CA
anders.rundgren> certificate using an X.509.v3 non-critical extension,
anders.rundgren> violates the very core of PKI and X.509, as the CA
anders.rundgren> cannot vouch for itself.
anders.rundgren> 
anders.rundgren> Isn't that what a CP doc does today but without using
anders.rundgren> cryptographic bindings?
anders.rundgren> 
anders.rundgren> In my opinion such an extension is principally no
anders.rundgren> different than CAs having Subject DNs like
anders.rundgren> "CN="TrustUS High-value CA".
anders.rundgren> 
anders.rundgren> Any opinions on this?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 5 Feb 2004 12:15:51 +0100

Thanx Richard,
And I agree 100%.

Trust is indeed something that you establish using various out-of-band
methods.  CA metadata can only help a [tiny] bit here.

I primarily regard Metadata as potentially useful in a PKI context once
trust has been established.

If you view properies on a CA-cert (be it self-signed or not), augmented
with metadata you could preferably look on things associated with the
issuance.  This vould be analogous to viewing properties on a file system
folder, where you typically get an indication of how many files there are
in the folder.  That is, metadata is an administrator thing.

Anders

----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 05, 2004 10:54
Subject: Re: Adding Metadata to PKI = ERROR?

Dear Anders,

In message <006c01c3ebbb$7268d330$0500a8c0@arport> on Thu, 5 Feb 2004 08:41:01 +0100, "Anders Rundgren" <[email-masked]>
said:

-----

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 05 Feb 2004 13:29:26 +0100 (CET)

Anders,

I hear what you say, but I can't see the use for it, and you're not
being very specific about it (you say that you can look at them as you
would look at properties in a file system, but that's hardly something
I consider useful).

The way I see it, when you place trust in a CA, and in the set of
policies it comes with (or perhaps just s subset), what you usually do
is to store that CA cert somewhere in a database (the Windows key
store, the OpenSSL certificate directory, whatever) and decide to
trust things signed with the corrresponding private key.  Since the
path validation algorithm in RFC3280 doesn't care about policy
pointers in a self-signed CA certificate, you have to indicate with
some other means what policies you want to place trust in (unless you
go for anyPolicy), and I would attach them to that CA cert.  The
alternate thing to do is cross-certify if you have your own CA (and
you can do it one-way if you choose to), but at that point, it's your
own set of policies that are important, and not theirs any more,
except for the purpose of policy mapping.

What I see here is a crucial philosophical difference.  If you would
use the policy OIDs that come in some self-signed CA certificate, it
would mean that the CA dictates exactly what policies your accepting,
and you would have to follow suit with CA cert upgrades.  On the other
hand, if you aquire the policy OIDs by other means, you're your own
man and noone else can tell you what you trust or don't trust.  With
that in mind, policy pointers in self-signed CA certificates is just
redundant information and could be regarded as a curiosity to watch
when you feel like amusing yourself in perverse ways, or at worst a
possible source of confusion since there may be a time that they don't
match what you have in your "policy trust database" (whatever that
would be), making the administrator wonder what's what.

NOTE: This is *my* interpretation.  If there's something I've
misunderstood here, I would deeply appreciate it if someone would
correct my errors.

In message <01e001c3ebd9$6a763c30$0500a8c0@arport> on Thu, 5 Feb 2004 12:15:51 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Thanx Richard,
anders.rundgren> And I agree 100%.
anders.rundgren> 
anders.rundgren> Trust is indeed something that you establish using
anders.rundgren> various out-of-band methods.  CA metadata can only
anders.rundgren> help a [tiny] bit here.
anders.rundgren> 
anders.rundgren> I primarily regard Metadata as potentially useful in
anders.rundgren> a PKI context once trust has been established.
anders.rundgren> 
anders.rundgren> If you view properies on a CA-cert (be it self-signed
anders.rundgren> or not), augmented with metadata you could preferably
anders.rundgren> look on things associated with the issuance.  This
anders.rundgren> vould be analogous to viewing properties on a file
anders.rundgren> system folder, where you typically get an indication
anders.rundgren> of how many files there are in the folder.  That is,
anders.rundgren> metadata is an administrator thing.

-----