Folk,
Some colleagues and I have presented a paper in the IFIP Upper Layer
Protocols, Architectures and Applications (ULPAA'94) International
Conference to be held in June in Barcelona (Spain). As far as I know,
it seems that the paper has been accepted. The paper proposes a
certification system inspired on PEM and PASSWORD works.
The intention of this mail is to provide you a summary of the ideas
described in such a proposal. I hope you find them interesting, and any
comment or contribution will be appreciated. On the other hand, if
seasonable, we are interested in including your comments in the paper,
besides the ones from ULPAA referees.
The proposal assumes the following points:
Hierarchical policy-based certification infrastructure.
Subset of X.509 recommendation and superset of PEM RFC-1422.
Use of X.500 Directory service is suggested but not strictly
mandatory.
Use of PEM certification layering.
And addresses the following issues:
Explicit specification of policies in certificates.
Explicit specification of certification hierarchy in certificates.
Multiple hierarchies, the international reality.
Naming and certification relationship.
Pull (versus push) certificate validation model.
Unambiguous identification of entities' role (PRA, PCA, UCA,
users) and certificates with the same public component.
The proposal is based on X.509 (1992), but also implementable with
X.509 (1988), certificate format. Moreover, new certification
semantics are introduced to this format. The proposed ASN.1
certificate format shows as follows:
Certificate ::= SIGNED SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT CertificateIdentifier OPTIONAL,
subjectUniqueIdentifier [2] IMPLICIT CertificateIdentifier OPTIONAL,
}
Version ::= INTEGER { v1(0), v2(1) }
CertificateIdentifier ::= SEQUENCE {
policyId [0] IMPLICIT BIT STRING OPTIONAL,
praId [1] IMPLICIT BIT STRING OPTIONAL,
cpathId [2] IMPLICIT BIT STRING,
userId [3] IMPLICIT BIT STRING OPTIONAL
}
As you may note, the certificate format is exactly the one defined in
X.509 (92), but we have changed the BIT STRING to be
CertificateIdentifier type. The fields in this new data type mean:
Policy Identifier (policyId): It contains a unique identifier for a
given policy. This policy will be enforced by a Policy Certification
Authority (PCA) -see PEM RFC-1422-.
Policy Registration Authority Identifier (praId): We also named it top-
level authority and contains a unique identifier for a given
hierarchical top-level registration authority. This authority will
endorse particular policies in its certification domain.
Certification Path Identifier (cpathId): It contains a chain of
hierarchical certificate serial numbers forming a unique identifier
for the last certificate in the chain.
User Identifier (userId): It contains a user-related unique identifier
and will usually be some other form of certification on the validity
of the distinguished name.
The point now is how to obtain unique worldwide identifiers to use in
those fields. In the meanwhile that there does not exist a true worldwide
coordinated registration authority for policies, we can proceed in an
ad-hoc way. For the rationale, imagine the case of PEM:
From RFC-1422 text: "... Beneath IPRA root are Policy Certification
Authorities (PCAs), each of which establishes and publishes (in the
form of an informational RFC) its policies for registration of users
or organizations...".
In this case, the "policyId" unique identifier can be the hash value
of the published informational RFC document. Making explicit this
value in a certificate, we are irrefutably linking the certificate to
a public-known policy. That means, for instance, if the policy
changes, i.e. the policy statement is modified, the certificate is
directly influenced by this change. Although, policy statement are
supposed to be stable for long periods of time.
In the case of "praId" unique identifier (for instance, PEM IPRA), we
can also use a hash value of the certification hierarchy statement,
i.e. the RFC-1422 document. For top-level authorities, we can
alternatively construct the unique identifier by applying the hash
function to the entity's Distinguished Name (DN) or even use the top-
level authority public component as unique identifier. We can not use
a hash value of a DN or other value in the case of policies, since we
want to identify the policy not the entity enforcing such a policy (it
can exist different entities -PCAs- enforcing the same policy). In the
case of a top-level authority we want to identify a certification
domain, for instance that of PEM by means of the IPRA.
The certification path identifier "cpathId" is represented by a
sequence of integers as in an ASN.1 OBJECT IDENTIFIER data value, that
is, "nt.np.nu..." where each node is a hierarchical certificate serial
number for a given certification layer. Supposing the general format
"nt.np.nu1.nu2...num", then:
nt is the key version number (or serial number) of the key pair used
by the top-level authority to sign underneath PCAs. That is, first
key will have nt=1, if compromised of changed, the following key
will have version 2, i.e. nt=2.
np is the serial number of a hierarchical certificate issued to a
PCA by a top-level authority. This is the normal process for
policy endorsement in a certification domain.
nu is the serial number of a hierarchical certificate issued to a
User CA (organizational, PERSONA, Residential, etc.) by a PCA.
This is the normal process for CA registration in a policy domain.
As there can exist different levels of UCAs, the same rule applies
when UCAs delegate to other UCAs. Then, each CA level is present
as a different node in the cpathId.
The construction of a cpathId resembles the process of delegation in a
CA hierarchy. Moreover, uniqueness is explicitly guaranteed within a
certification domain because CAs must guarantee uniqueness of local
serial numbers. So, this is a very easy and not central method for
having a more extended concept of certificate serial number. Of
course, this is not new, OBJECT IDENTIFIERS are widely assigned in
this way.
The "userId" field can be any free BIT STRING.
As an example, suppose the PEM hierarchy having the IPRA a hash value
of '00AABB...'H and having the RSA Low Assurance PCA (RLA-PCA) policy
document a hash value of '22CCDD...'H. IPRA is using its first key
pair and has assigned serial number 2 to RLA-PCA certificate. Then,
the certificate of a UCA certified by this PCA may look like:
uCACertificate = {
version { 1 },
issuer { RSA Low Assurance PCA },
serialNumber { 7 },
subject { ...; O=Organization },
issuerCertId {
policyId { '22CCDD...'H },
praId { '00AABB...'H },
cpathId { "1.2" or '0102'H }
},
subjectCertId {
policyId { '22CCDD...'H },
praId { '00AABB...'H },
cpathId { "1.2.7" or '010207'H }
},
}
By deeply studding this proposal, we have found several advantages
(comparing it with existing ones, plain X.509, PEM, PASSWORD, X9,
PKCs). Some of these advantages are:
As we now have explicit the relationship between a certificate
issuer and the subject via the certificate identifiers (issuer and
subject CertId), it is not absolutely necessary to make this
relationship explicit by means of the naming hierarchy. We think
that naming rules should be enforced by policies but not by the
top-level authority to the whole certification tree. For instance,
this can be useful for PERSONA CAs.
By inspecting the CertIds of a certificate alone, it is easy to
deduce the class of such certificate, i.e. if the certificate
belongs to a PRA, PCA, UCA or a user entity. Then, there is not
need of a mandatory naming rule to distinguish CAs from users
certificates. For instance, naming a PCA as it was an
organization. A PCA is a policy object not an organization.
Using issuer_DN plus subjectCertId fields for identifying a
certificate is better than using issuer_DN plus serial_number. For
instance, we have solved the problem of multiple certifying the
same public component. NOTE that if we agree in a fixed length for
policyId and praId values, then we can represent a CertId as a
unique number, for instance '00AABB22CCDD010207'H, and then
consider it as a certificate serial number.
CertId or even the couple "praId"+"cpathId" are universally unique.
It does not merely identify a person by means of a public key (as
some approach), but identify such person, the public key and the
context under that public key was certified. So, we can use the
CertId as primary identification key, and in conjunction with a
DN, we lead to previous assert.
Thinking in a Pull certificate validation model, the CertId provides
the verifier with policy and certification path information that
may notably help the certificate validation process.
Having policy information at certificate level joins the certificate
to a policy in a clearer way than having the policy at
certification path level.
In a multiple hierarchy scenario, having a reference to a particular
hierarchy explicit at certificate level links the certificate to
such hierarchy in a clearer way than deducing the top-level
authority in a certification path.
Having CertIds we can easily represent cross-certificates for
connecting different certification domains (hierarchies) both in a
global basis or in a per-policy basis. Contrary on that proposed
in PASSWORD, we prefer certification domains inter-connection
through top-level cross-certification. We have also thought in a
easy (and trusted) method for inter-connecting certification
domains.
The proposed certificate semantics allows to determine if a
certificate was issued within a complete certification hierarchy
(i.e. there are PRA, PCA and UCAs) or, on the contrary, it was
issued within a not complete hierarchy, for instance, there is not
PRA (as currently in PEM) but the PCA has a selfsigned
certificate. Even, the certificate can inform about a particular
hierarchy form or the absence of hierarchy at all.
The certificate encoding will grow less than 40 bytes depending on
the chosen policyId and praId identifiers encoding.
etc.
In short, we think that our approach gives real solutions for some
current problems with minimum extensions to current X.509 (88) based
infrastructures, and it proposes the X.509 (92) certificate as the
basis for a future infrastructure. We are in the line of X.509
recommendation and ANSI X9 that use X.509 (92) certificate format as
well. I do not understand why the PKCs use X.509 (88) and propose an
extended certificate format. With respect this issue, we prefer ANSI
X9 approach and its attribute certificate concept rather than PKCs.
Anyway, this another discussion.
If you find interesting this proposal, please feel free to send me any
comment. As first step, we will use the comments to improve the paper
for ULPAA conference. Further, we can make public the paper and
related material.
Francisco Jordan
Group of Distributed Systems
UPC - Universitat Politecnica de Catalunya
Barcelona - Spain
PD Apologizes for my hard to read English.