[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: X.509 ACs vs. SPKI?




Stephen Kent wrote:

> 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.

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.

> 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.

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.

> 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.

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                                 egerck@mcg.org.br
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---