Subject: RE: X.509 ACs vs. SPKI?

From: "Ellison, Carl M" <[email-masked]>
Date: Mon, 24 May 1999 17:38:00 -0700

Russ,

nit picking:

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, May 24, 1999 1:58 PM
> To: Carl Ellison
> Cc: Ari Huttunen; [email-masked]; [email-masked]; Carl Ellison; Carl
> Ellison
> Subject: Re: X.509 ACs vs. SPKI?
> 
[snip]

> 
> X.509 ACs offer three methods of binding the attributes to an 
> owner.  They
> each offer different advantages and disadvantages.
> 
> 	(1) Issuer Distinguished Name and Serial Number.  This binds the
> attributes to a particular X.509 public key certificate.

IssuerSerial does not identify a particular X.509 certificate.  The
problem is that an Issuer Distinguished Name does not identify an
issuer uniquely, since there are no distinguished names except in name
only.  If the X.500 dream had come true there might be, but it hasn't
and won't.

> 	(2) Subject Distinguished Name.  This binds the 
> attributes to a collection
> of certificates that were issued to the same subject, perhaps 
> by different CAs.

Again, since there are no distinguished names, especially from
multiple issuers, you can't identify certificates issued to the same
subject merely by comparing DNs.

 - Carl

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 May 1999 14:41:32 -0400

Carl,

I agree that the only safe way to bind an attribute cert to an identity
cert is via the public key hash. That's what I always recommend to my
clients.

Look at the draft profile for attribute certs recently published by Stephen
Farrell and it's easy to locate the key hash as pointer.  The real
difference here is that X.509 believes that certs with public keys should
contain a name that is not purely a local matter.

The hash is the most secure way to bind an attribute (yes, "authorization"
is a better name) cert to the identity cert, and I'll suggest that we
mandate it in our profile as we progress.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 25 May 1999 16:21:30 -0700

> cert is via the public key hash. That's what I always recommend to my

Actually, if you want to bind X to an identity cert the only secure way is
via that cert's hash as a whole, not the public-key hash.  In fact, the cert
hash is not simply the only unique reference that you can rely on for that
identity cert, but also one which (by extension from the cert) already
includes a revocation mechanism (CRL or OCSP) and possibly also
insurance or derived warranties (via CA CPS).

I note that the cert hash has been suggested as an intrinsic DN two years
ago [Ger97a], which can be entirely locally defined and with a local
decision tree that allows its local reconstruction at any time -- yet globally
unambiguous.

Of course, if you want to bind X to a public-key then you are justified to
do what you mentioned. But,  the CRL-authority for that public-key
cannot be securely defined neither by the keyholder nor by delegation
to the identity cert issuer -- which is a serious security fault. Besides, you
would lack insurance and other warranties which can be directly derived
by extension from the cert -- since no cert is named.

> contain a name that is not purely a local matter.

This is not correct, though a common misconception and unfortunately often
so cited in some SPKI  documents. Let me divide the issue in three parts:

1. Section 3.3.3 of X.509v3 defines a certificate as: "user certificate;
public key certificate; certificate:  The public keys of a user, together
with some other information, rendered unforgeable by encipherment
with the private key of the certification authority which issued it.". But,
what is "some other information"?

2. Section 11.2 of X.509v3, "Management of certificates", states that
the certificate allows an association between a name called "unique
distinguished name" or DN for the user and the user's public-key:
"A  certificate  associates  the public key and unique distinguished
name of the user it describes.", while Section 7 explains that such
DNs are essential to the security design of X.509: "Authentication
relies on each user possessing a unique distinguished name." But,
how are such DNs assigned? Where are they unique? Locally,
globally?

3. The DN is denoted by a NA (Naming Authority) and accepted by a
CA (Certification Authority) as unique within the CA's domain, where
the CA can double as a NA. It is interesting to note that the same user
can have different DNs in different CAs, or can use the same DN in
different CAs even if it is not the first one to use it in a CA -- so different
DNs for different CAs do not necessarily mean different users and vice-
versa.  Further, a DN does not have to contain the user's real-world
name or location. Thus, semantically, the CA certificate refers to a name;
however it does not denote it.

Thus,  these three points deny the affirmation that a X.509 name is "not
purely a local matter" -- yes it is since the CA is local, but it could
nonetheless *also* have a global significance (for example, if that name
correctly dials a fully-qualified phone number).

However, there is one more point in X.509 which can be interesting here,
regarding the validation of such DNs -- which is also *local* to the CA,
not global at all and also not necessarily auditable:

4. X.509 is moot on validation procedures for data included in a certificate
such as the user's name, with the exception of validation procedures for the
user's public-key which are suggested (not mandated) in Section 10 of
X.509v3. For example, regarding validation procedures for the user's
identity, Section 11.2.a states that: "a certification authority shall be
satisfied of the identity of a user before creating a certificate for it", which
means that identity validation procedures are to be satisfied in the CA's
frame of reference by following the CA's own self-defined rules (called CPS),
which are declared outside the scope of X.509 and can be entirely different
for different CAs. Further, all public CA's CPSs accept indirect references
of "trust" when issuing certificates, which is a security risk that could only be
acessed by  auditing, to verify the procedures used to accept an ID for example
-- but, auditing is not possible with today's CPS and X.509 is also moot on such
requirement.

Thus, X.509 focuses on defining a mechanism by which information can be made
available in a secure way to a third-party. However, X.509 does not intend to
address the level of effort which is needed to validate the information in a certificate
neither define a *global* meaning to that information outside the CA's management
acts.

In legal reliance terms, one may trust the DN confirmation procedures of the CA
during certificate reliance, but one cannot rely upon them for other than their value
as a representation of the CA's authentication management act expressed in the
CA's own terms and rules (CPS) -- therefore, a DN in a X.509 certificate is *by
X.509 definition* a purely local matter (local to the CA and its CPS) even if
X.500 global directories were used (X.509v3, Section 11.2). Of course, if the US
INS accepts (rather, "uses") UK birth certificates in order to issue residence
permits to the US, this does not mean that the INS is declaring that such birth
certificates are valid in the UK. So, the eventual use by a CA of a DN supplied
by a X.500 directory does not mean that the CA is declaring that such DN is
global.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified --   is also outside the scope of PKIX and depends
on each CA's CPS.

See [Ger97b] for further comments.

> mandate it in our profile as we progress.

As above, I agree if by "hash" one means the whole identity certificate hash -- not the
public-key hash.

Cheers,

Ed Gerck

REFERENCES:

[Ger97a] http://www.mcg.org.br/cie.htm

[Ger97b] http://www.mcg.org.br/certover.pdf
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [email-masked]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 May 1999 17:56:17 -0400

Ed,

>insurance or derived warranties (via CA CPS).

Interesting point.  If one wants to ensure that the whole context of the
identity cert is bound to the AC then you are right.  That is the most
conservative, and probably the most secure appraoch.  There might be
occasions where I don't want so tight a binding, and where just the key
would be OK, which does have a more SPKI-like flavor.  The other extreme is
linkage via the subjecvt name, which is more flexible, but also more
dangerous in some contexts, as other have pointed out.

>decision tree that allows its local reconstruction at any time -- yet globally

Cert hashes are not, IMNSHO, a good ID form. For example, they don't admit
to easy searching over a distributed set of databases, unlike
tree-structured names, e.g., DNs or DNS names, or IP addresses. It's not
enough to make an ID globally unique.

>by extension from the cert -- since no cert is named.

A common model for use of ACs is that they are issued by an authority for
later presentation to an access controller for resources controlled within
the same domain as the issuing authority.  Under than model, it is unlikely
that the trace back to a specific cert (in case multiple certs hold the
same public key) is really a problem.  Also, since the authority that
issued the AC would have had access to the identity cert as part of the
issuance process, it can always keep a copy in an audit trail for later
matching to the specific cert against which the AC was issued, if a dispute
arises.

>not global at all and also not necessarily auditable:

Nice analysis, but it ignores the context in which X.509 exists, i.e., the
X.500 directory model.  People do issue X.509 certs with subject and issuer
names that may not be globally unique, but that was not the context in
which cert issuance was envisioned.  I don't worry too much about folks
issuing certs with names that are unique local to a CA context, as you
observe, so long as they understand the possible adverse implications of
such.  Given the lack of a global X.500 directory, I usually advise folks
to stick with name spaces that do have global uniqueness and some extant
authority for managing the name space, e.g., the DNS, or to construct a
purely local system.

>neither define a *global* meaning to that information outside the CA's

Of course X.509 does not establish the criteria that a CA will employ for
authenticating the right of an EE to use the subject name.  That is a local
policy matter, even for globaly names.

>by a X.500 directory does not mean that the CA is declaring that such DN is

To expand on your example, when the US issues a passport, it states that
the named individual is a citizen of the US and that the name represented
in the passport is a legal name for the passport holder (the later binding
established via the photo).  If one were to issue an electronic passport,
the DN for the passport holder probably would include the passport number
as a component of the terminal RDN. to ensure uniqueness in the space for
which the US Dept of State is authoritative.

>how such association was verified --   is also outside the scope of PKIX

Yes, the means fo verification is a CPS issue, but also don't get too hung
up on DNs, per se.  PKIX encourages use of altName forms suitable to the
Internet environment, where global uniqueness is a reasonable presumption.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 27 May 1999 13:58:26 +0200

Steve,

I have a comment on this E-mail.

> cert is via the public key hash. That's what I always recommend to my

I wonder if it is a good recommendation. :-(  This may be appropriate in some
contexts but not in general.

A user may have two public key certificates with two different names but with
the same public key. In that case it is not always possible to know with which
of the two certificates the AC is associated.

> mandate it in our profile as we progress.

I would not follow that suggestion but instead suggest in our profile the
support of the identification of the public key certificate the AC is
associated with.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 May 1999 10:12:01 -0400

Denis,

Yes, there is a problem with tying an AC so closely to a key, or even to a
cert in its entity, as Russ pointed out to me in a private message.  One
can imagine a spectrum of binding, from the subject name to the public key
hash, to a hash of the whole cert.  The tighter the binding, the less
opportunity for confusion or for malicious rebinding. Tighter bindings may
require duplicate ACs, as in the examples you and Russ provided, and more
frequent reissuance, based on identity cert reissuance.  However, I am very
concerned about security lapses here, so we will need to carefully evaluate
the benefits and costs of different approaches to effecting the binding.
Issuing additional ACs because of a key hash or cert hash binding may not
be so bad.  Still, I may have overstated the need to use these hashes in
all cases in ourt profile.

Steve

---

From: [email-masked] (Terry Hayes)
Date: Thu, 27 May 1999 08:44:02 -0700

> of the two certificates the AC is associated.

I believe that this is the point.  The AC would be associated with the key, not
with any specific certificate.  Yes, that means there is no published expiration
time for the key, no way to check revocation (except perhaps with the keyholder),
and no way to associate a global name with it.  The last time I checked, it was
still possible to use key pairs without having a certificate associated with them!
:)

Validity time, and revocation services would only apply to the AC itself it this
environment.

Terry

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 May 1999 12:23:53 -0400

Terry,

>still possible to use key pairs without having a certificate associated

In the X.509 AC model, the key is extracted from a validated identity cert,
and that cert does contain the management data about key lifetime, etc.
It's just that the AC is used as an important input for rule-based (maybe
role-based too) access control decisions, rather than just using the
identity in the certificate.  Putting a key hash in an AC does not make it
into a SPKI cert :-).

Steve

---

From: Carl Ellison <[email-masked]>
Date: Thu, 27 May 1999 09:21:40 -0700

[snip]
> Validity time, and revocation services would only apply to the AC itself it this

In SPKI, we distinguish between the terms "attribute cert" and "authorization
cert".

When I give talks on this subject, I draw a triangle whose vertices
are labeled Name, Permission and Key.  (I draw it with name on top and
key on the right.)

The goal for us application developers is to map a Permission to a Key,
but we can go from left to right in two different ways.

We can take an authorization cert directly from Permission to Key or
we can take a pair of certs:  attrubute cert from Permission to Name and
id cert from Name to Key.

To do that latter path, you have to identify the Name in a globally
unique way.  Since there are no globally unique (ie., distinguished)
textual names and there never will be (IMHO), we choose to make
names unique by using what we call a Fully Quanlified name:

	(name <key> n_1 n_2 ... n_k)

where <key> is the public key (or its hash) of a name issuer.  In the
X.509 world, this is the root key of a hierarchy.

n_i are the names from that (root) key to the particular name we
care about.  In X.509, this would be the names of the CAs enroute from
the root key to the leaf name.  In SPKI, it's a SDSI name chain.
The two are equivalent, from the point of view of the authorization
computation.

What I was trying to say about X.509 ACs was that a form that turns it
into an authorization certificate can be interpreted unambiguously, but
if you want to use it as an attribute certificate, it's missing the ability
to specify a Fully Qualified name.

 - Carl

-- 
 Carl M. Ellison   [email-masked]     http://www.pobox.com/~cme
 PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2
 ``Officer, officer, arrest that man!  He's whistling a dirty song.''
     [Jean Ellison]

---

From: Carl Ellison <[email-masked]>
Date: Thu, 27 May 1999 09:53:54 -0700

> names unique by using what we call a Fully Quanlified name:

I used sloppy wording here and want to forestall a storm of replies
pointing that out.

There are *many* globally unique names: phone numbers, e-mail addresses,
US SSN, ....  What there isn't is a *single* globally unique name system.
That's what I mean by "distinguished name" (lowercase, to distinguish it
from an X.500 DN).  Of course, X.500 once thought it was going to produce
distinguished names and much of its design is based on that assumption.
This implies a value system difference and we know from psychology
that a value system difference produces religious debates that never
resolve.

 - Carl

---

From: "Dale Gustafson" <[email-masked]>
Date: Thu, 27 May 1999 13:33:38 -0500

Steve,

A couple of questions:

1) Has anyone described this AC Model in summary form ?

2) Is there an assumption that an AC "must always" contain a reference to an
x.509 ID-cert ?

3) Can an AC contain ...

 - a pointer to an ID-cert { Issuer DN, Serial Number, Key Hash } ?
 - a reference to an ID-cert (ID-cert Hash) ?
 - a full copy of an ID-cert ?

4) Is it a general and extensible model or something that can accomodate
selected access control applications only?

Best Regards,

Dale Gustafson

---------------------

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 28 May 1999 11:22:14 +0200

Steve,

I agree with your response

In ESS (from the S/MIME WG) there is the following structure which unambigously
references an certificate.

ESSCertID ::=  SEQUENCE {
     certHash                 Hash,
     issuerSerial             IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {
     issuer                   GeneralNames,
     serialNumber             CertificateSerialNumber

I suggest that we generalize it, to support any kind of HASH function, i.e. not
limiting it to SHA 1. In addition IssuerSerial should be made mandatory instead
of optional (there was a good reason to make it optional in ESS/CMS, because
the information was normaly already present in the CMS structure).

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 May 1999 11:25:11 +0100

Dale,

(Different Steve here, but never mind:-)

I hope that the ACs I-D does contain exactly that. I'd certainly
be interested in your comments if it doesn't!

The I-D's at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-00.txt

Regards,
Stephen.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 May 1999 10:46:08 -0400

Dale,

Two Stephen's no waiting :-).

>1) Has anyone described this AC Model in summary form ?

see the I-D as a starting point for PKIX discussion.

>2) Is there an assumption that an AC "must always" contain a reference to an

My view of the model says yes.  ACs don't exist independent of public key
certs.

> - a pointer to an ID-cert { Issuer DN, Serial Number, Key Hash } ?

yes.

> - a reference to an ID-cert (ID-cert Hash) ?

I hadn't thought about that, but maybe.

> - a full copy of an ID-cert ?

I hope not. just as we strive to incorporate policies by reference (through
OIDs) we would not want to stuff another cert into an AC.

my responses for these questions are based not on what one might be able to
do, syntatically, based on the X.509 spec, but what we ought to profile
based on a larged context model of how ACs are to be used.  we used to have
debates in PEM and in PKIX about whether one could use any attribute
defined for an X.500 directory entry as an RDN component in a subject or
issuer name.  there was no syntactic prohibition against it in X.509, but
it violated the model of what a DN is, and thus ought not be put in subject
or issuer names.  that same notion of what's the model and thus what ought
one do with ACs should be a part of discussion here.

>selected access control applications only?

We all want something general and flexible, but to ensure reasonable
interoperability we have to temper those characteristics a bit.  certainly
we envision use of ACs for a wide range of PKI-enabled Internet apps, e.g.,
S/MIME, SSL, IPsec, ...

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 May 1999 18:27:51 +0100

Only minor quibble I'd have is...

> My view of the model says yes.  ACs don't exist independent of public key

Its also possible, though most likely out of PKIX's scope, for an 
AC to be linked to e.g. Kerberos authentication or some other
symmetric based mechanism.

Regards,
Stephen (the one just finishing his shift:-)

---

From: Ed Gerck <[email-masked]>
Date: Fri, 28 May 1999 18:30:58 -0700

Stephen Kent wrote:

> conservative, and probably the most secure appraoch.

That is why I suggested that  PKIX should follow this approach -- also
because the corresponding CRLs, OCSP, CPS, warranties and
insurance are included by unambiguous reference. A lot more can thus be
easily gained if so desired by the verifier, not just improved validation
assurances.

> There might be
> would be OK, which does have a more SPKI-like flavor.

I just commented on the SPKI list that this is a security fault also in
SPKI, where the issuer is the same entity as the verifier.  Here, however,
this thread deals with X.509-SPKI -- not SPKI-SPKI for issuer-verifier.

As I also just commented there, the SPKI-SPKI case can be even
simpler. In fact, who needs even the key hash in that SPKI attribute cert?
Simply by signing the SPKI attribute cert with the corresponding private-key,
the issuer would force himself at a later date (when he becomes the verifier)
to use the corresponding public-key in order to verify the attribute cert's
signature. No need for a key hash entry for that same public-key in the
attribute cert -- the binding of the attribute with that public-key is implict
but strong, in the cert signature itself.

Things do tend to get simpler thus, when one is talking to himself.

Can this be useful? Perhaps, as a type of crypto memory  for myself --
but not for this X.509 ACs vs. SPKI thread.

Thus, if communication or e-commerce enter the picture and the
verifier is no longer the issuer, then one can no longer assume that to
each public-key there is a unique certificate (as SPKI does).

Is there a solution? I believe so as I wrote before, both for SPKI-SPKI
as well as for SPKI-X.509  -- by simply using the whole cert hash instead
of the key hash. Then, the key is referred together with its validation and
revocation context.

> enough to make an ID globally unique.

There is a simple confusion above, IMVHO. It is misleading to say that
cert hashes are not "a good ID form" -- and then try to support this
affirmation by noting their undesirable *pointer form* while, at the
same time, affirming at the end that indeed they have a good ID form
because they are "globally unique".

An apple is a bad speedboat, allright.

Thus, the issue here is quite different. Is a cert hash a good ID form in  the
sense that it allows *all* relevant variables (public-key, date of issuance,
issuer, etc.) that define the issuance and validity of a public-key to be
unambiguously and compactly referenced in it -- as their joint  ID? Yes,
must be the answer here. Contrary to the previously preferred key hash,
for which the answer must be a flat No.

Now, regarding their performance as hierarchical *pointers* -- obviously,
*both* hashes are equally bad. So, I would say IMVHO that using cert hashes
instead of key hashes certainly did NOT make the matter *worse* in this
regard. Which matter was however already acceptable, so there is no reason
to refute it now, based on these grounds.

But, this can also be solved -- by using cert hash fingerprints, directly derived
from the cert hashes, as a conveniently small but probably unique pointer. In
the same way that we use key fingerprints for CAs, no?

> matching to the specific cert against which the AC was issued, if a dispute

This reasoning only applies to networks, not to internets. Take away that
common authoritative point and the problem surfaces. But, even to networks,
it applies only very poorly. For example, if the same authority issues two
different certs for the  same key (the newer cert with less warranty, for
example), then neither can you define which identity cert supports the
attribute cert nor, in the case of a revocation of the older identity cert
with more warranties, whether that attribute cert is even valid at all.
Conversely, even when restricted to a network, you can be easily
spoofed into accepting an invalid attribute cert since you do not know
which identity cert supports it -- the one with more or less warranties.

That is why I considered such usage a serious security fault. But,
there are other examples of this logic.

> X.500 directory model.

No, it does not, please read again  -- *even* if X.500 would exist, a DN
in an X.509 certificate would still be a locally defined name. As I originally
commented below and I requote:

 In legal reliance terms, one may trust the DN confirmation procedures
 of the CAduring certificate reliance, but one cannot rely upon them for
 other than their value as a representation of the CA's authentication
 management act expressed in the CA's own terms and rules (CPS) --
 therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
 local matter (local to the CA and its CPS) even if X.500 global
 directories were used (X.509v3, Section 11.2).

> People do issue X.509 certs with subject and issuer
> which cert issuance was envisioned.

This was not the point. Even if the name were globally unique the validation
was envisioned by X.509 to be local to the CA and that is why each CA
can define its own CPS.  To repeat, from X.509, Section 11.2:

 "a certification authority shall be satisfied of the identity of a user before
 creating a certificate for it",

which affirms that any CA is authoritative over any X.500 directory, in the
CA's own terms and rules (CPS), contrary to what you suggest would
have been envisioned.  The whole text of X.509 is clear on this distinction
and that is why I cited more than one passage. Yet, this is often a source
of confusion -- perhaps because X.500 was an identification dream while
X.509 was living it ;-) But, X.509 had it right, IMO -- names are indeed
locally defined even if they have a very global significance or uniqueness.

There is thus an inherent conflict between the "global" affirmations of the
X.500 names mandated in X.509 and the laissez-faire doctrine behind
the X.509 definition of the CPS terms -- which is strictly local to *each*
CA. So, the very rules which define *what is valid* are local in X.509.

That is why names cannot take a global significance even if X.500 would
be "a dream come true", unless the CA would so define. But, the CAs
are ever so careful to affirm the opposite in their CPS. And, rightly so
[as I comment in http://www.mcg.org.br/cert.htm].  Also, given the fact
that 50% of the world's lawyers are in the US and the growing US
tendency for "jackpot justice" one wonders what else could be
expected from CAs -- and the Utah experience was an eye-openner
in this regard. Technical reliance cannot come from legal reliance --
but, exactly the opposite (BTW, this also applies to non-repudiation).

> I don't worry too much about folks

Your suggestion is IMO good. But, at the end, the name is locally defined
and is thus local. This also includes a broader issue -- that DNS and DN
names are intersubjective, not objective. Their meaning depends on both
ends. For example, if I give you the URL www.gifts.com -- what do you
think they sell? Surely, it is a simple name.

In general, it is useful to distinguish between names as syntatic expressions
(references, byte strings) in contrast to semantic expressions (sense, what
they mean or denote). And, this leads to the realization that reference and
sense are independent variables -- there can be no global meaning even
if the name is syntatically global.

> policy matter, even for globaly names.

Yes. This is one of the points, as I call attention to, that deny reading X.509
as mandating "global names" -- it does not, even though it supposes (wrongly,
see the sense vs. reference discussion above) that they exist somewhere
(X.500).

> which the US Dept of State is authoritative.

Yes, as well as date of issuance, validity, authority name, etc -- voila, a certificate ;-)

> Internet environment, where global uniqueness is a reasonable presumption.

Agreed. It seems that we are in substantial agreement especially as the reading
of this e-mail progressed to here, though less of a violent agreement in the
beginning ;-)

Cheers,

Ed Gerck
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---