Herein, I propose some solutions to current pem-dev concerns (email-
address, certification and naming hierarchy, Originator-ID, ...) based
on the CertId concept.
This is a new proposal based on a certificate having a unique
identifier named certificate identifier (CertId). Please refer to
previous mail "Subject: new proposal" in pem-dev list.
Since the first time I thought about 'CertId' concept, I realized that
it had to contain information about certification hierarchy, so that
we can separate certification from naming hierarchy. I think that
X.500 DNs should be used for naming objects. The primary function of a
name (X.500 distinguished name or Internet domain name) is to
unambiguously and uniquely identify an object (person, machine,
application, etc.). It's my opinion that try to adapt names (mostly
DNs) because a certification need is not the way. For instance, there
exist situations where strict name subordination is natural, but
others do not, etc.
The CertId contains precise certification information. If you now use
a NAME to identify the object that owns such certificate, then you can
make use of the existing NAME infrastructure.
Therefore, my conclusion is that if we handle certification and naming
information independently, we can probably have more success. In this
way, we will be able to assure that certificate "CertId+NAME" belongs
to a PCA or CA or user or anything else, and that it is within a
certification hierarchy because the CertId, irrespective of NAME
contains such information.
To shortly demonstrate the usefulness of CertId, imagine a hierarchy
as follows:
Top-level authority (policy register) with name Npra and certId
number 'n1'.
PCA with name Npca and certId 'n1.n2' because has been registered
by Npra. It has certificate Cpca = <Npra, n1.n2, Npca, Kpca>
UCA with name Nuca and certId 'n1.n2.n3' because has been
certified by Npca. It has certificate Cuca = <Npca, n1.n2.n3, Nuca,
Kuca>
User with name Nu and certId 'n1.n2.n3.n4' because has been
certified by Noca. It has certificate Cu = <Nuca, n1.n2.n3.n4, Nu, Ku>
Having this scheme, thinking in a PULL validation model and
irrespective of whether there exists or does not exist naming
subordination, I can always unambiguously identify a certificate by
means of its certId. For instance given certificate Cu, I can
unambiguously identify certificate Cuca which has certId 'n1.n2.n3'.
Moreover, if I want to get the certificate, I can access the X.500
directory and choose certificate 'n1.n2.n3' from entry Nuca (this is
not possible with plain X.509 (88) having entry Nuca more than one
certificate).
Other problem arises when the full certificate is not received in a
transaction but only the originator identifier (in PEM, field
Originator-ID-Asymmetric). For user Nu, suppose originatorId = <Nuca,
n1.n2.n3.n4>. Although having X.500 Directory services available, I
can do nothing with this information. I can check my local cache, but
imagine that it is not in. What to do?
You can think in having X.500 directory aliases from the issuer
(Ncua+n4) pointing to the subject (Nu). But, from my point of view, it
does not currently seem a trivial task.
Imagine for a while you have not X.500 directory service,
and you want to setup a PEM infrastructure for users that:
* usually handle RFC-822 email addresses,
* want to have certificates with X.500 DNs envisaging that in a future
X.500 directory services will be available.
* want to use current existing network services like Internet DNS,
* want PEM messages to contain only useful information, i.e. something
like PGP or RIPEM where there is no certificates nor certification
paths at all but only short key identifiers (pull validation),
* do not want to worry about manually getting public keys of other
users, but they want an automatic service,
* etc.
All these requirements are now possible by using the CertId concept.
Hint: Suppose that a user receives a PEM message from user Nu
containing no certificates, but only the Originator-ID-Asymmetric
field, i.e. originatorId = <Nuca, n1.n2.n3.n4>. How can I get the
certificate in order to validate the message?
Solution: Get the CertId = <n1.n2.n3.n4> and treat it as a
hierarchical network number, and try to resolve it as a Internet DNS
hostaddress to domain name information. To do that, we can define a
new domain name (like the one for resolving network addresses, i.e. IN-
ADDR.ARPA) with top-level domain name "CERT.ARPA". And now, we can
distribute the information as for IP network addresses. For instance,
SRI-NIC.ARPA will register CERT domains for "n1.CERT.ARPA", those in
turn will register domains "n2.n1.CERT.ARPA", etc.
Domain name servers managing CERT domains will contain records with
the following format (for instance):
nm...n2.n1.CERT.ARPA IN TXT "certificate as printable string"
If you want to know what certificates own a particular user by using
its email address, then you may use the following record (for
instance):
jordan.ac.upc.es IN PTR nm..n2.n1.CERT.ARPA
You can even store certificate revocation lists (CRLs) and treat it as
a different domain, for instance:
nc...n2.n1.CRL.ARPA IN TXT "CRL printable string"
(this is the record for a CA's CRL which certificate identifier is
nc...n2.n1).
You can use the time-to-live field (ttl) in a DNS record to inform
about the validity of the certificate or next issue date of a CRL in
order to control cached certificates and CRLs.
Imagine that Nu (above) is a user how has email address
jordan(_at_)ac(_dot_)upc(_dot_)es, and he sends a PEM message to a user X that
only
knows the very well-known root key Kpra (key from Npra with CertIf
'n1'). If the message only contain CertId = <n1.n2.n3.n4> as
originator identifier, can the recipient validate the message?
The answer is yes. The recipient can order the following DNS queries
in order to get all certification path information:
1) QNAME="n2.n1.CERT.ARPA", QTYPE=TXT
2) QNAME="n3.n2.n1.CERT.ARPA", QTYPE=TXT
3) QNAME="n4.n3.n2.n1.CERT.ARPA", QTYPE=TXT
Supposing that all names in certificates, i.e. Npca, Nuca, Nu are
X.500 DNs, can the user easily deduce that email address
"jordan(_at_)ac(_dot_)upc(_dot_)es" effectively belongs to user Nu?
The answer is 'may be'. It can be possible if the X.500 DN contains
the email address embedded in any of its attributes, or the DN is
formed by domain attributes, or whatever ad-hoc solution.
From my point of view, if X.500 DNs are complicated enough per-se, why
to artificially complicate DNs more!
I prefer a way similar to that described in PKCS#7 in section 9.2
SignerInfo type, that is, we can use something similar to an
EmailAddress (PKCS#9) authenticatedAttribute.
Imagine you put in the PEM message the following PEM-header field:
Authenticated-Attribute-EmailAddress:
<emailAddress>, <CertId>, <signedDigest>
* emailAddress is a valid Internet email address, for instance:
jordan(_at_)ac(_dot_)upc(_dot_)es(_dot_)
* CertId is the unique worldwide certificate identifier. So far you
have only a way of uniquely identifying a certificate, i.e.
issuerDN+serialNumber.
* signedDigest is a message digest of data <emailAddress>,
<certificateIdentfier> data encrypted with private key whose public
key is referenced by certificateIdentifier. For instance, algorithms
for digest and signature are the same that those for the certificate.
You can go beyond and use the attributeCertificate from ANSI X.9,
where it is possible to have attributes certified by other parties.
For instance, a public email service can automatically issue an email
attributeCertificate to user X after verifying X's certificate.
The procedures described herein are very easy to implement and will
not considerably impact on current PEM implementations (remember the
CertId can be coded as a certificate serialNumber in a X.509 (88)
certificate, as an IP address represented in dotted notation or as an
integer number).
NOTE that you can optionally even push PEM-header Originator-Certificate and
Issuer-Certificate fields in order to validate the attribute (of
course, as the emailAddress was signed by the originator you should
previously validate its certificate).
With this scheme, we can use X.500 DNs in certificates to uniquely
identify users, but we CAN use CertIds, email addresses and Internet
DNS for certificate management meanwhile an ubiquitous X.500 directory
service does not exist. Even when ubiquitous, it can be used both
X.500 and DNS as the user prefer.
Conclusion. Using CertId hierarchical numbers:
* You can take profit of existing NAME infrastructure for certificate
management while preserving X.500 DN as identity for an object. To
identify a certificate it is not explicitly needed a NAME but this can
help to access external resources.
* You have explicit certification hierarchy in the CertId, so you can
optionally relax naming rules.
* Because the explicit hierarchy of a CertId you can use this figure
for directly access and traverse distributed data bases to get
certificates.
* You can unambiguously identify a public key having also
certification hierarchy, policy and top-level authority information.
In the identifier, there is much more information than plain X.509
provides (which need to use the full certification path), and much
more than PGP and RIPEM (which use the public key as identifier).
* The last but most important, it is now possible to create a
worldwide certification infrastructure with current existing means.
Comments are wellcome. Thanks.
Francisco Jordan
Group of Distributed Systems
UPC - Universitat Politecnica de Catalunya
Barcelona - Spain
jordan(_at_)ac(_dot_)upc(_dot_)es
1994/03/16