Folks,
Following I present more ideas in the line of my previous mails
containing a proposal for using certificate unique identifiers.
In particular, this mail treats the trust model (hierarcical, direct)
connectivity and scalability of the system.
Cheers,
Francisco Jordan
*** For Warwick Ford eyes' only.
*** My previous mails on this proposal are in pem-dev list under:
*** Subject: new proposal Date: 94/03/09
*** Subject: email addresses, pull validation model... Date: 94/03/17
***
*** I sent you these messages but your MTA returned me a delivery failure.
-----
Trust and Connectivity Model based on Certificate unique Identifiers
--------------------------------------------------------------------
Some days ago I gave a short overview on a proposal about introducing some
explicit certification information in certificates (pem-dev list message,
subject: new proposal).
In the proposal, a certificate has now EXPLICIT information about the
issuing top-level authority (e.g. IPRA), the enforced policy and the
certification path till the subject certificate. All three information are
what I named Certificate unique Identifier or "CertId" (A certificate as
defined in X.509 -1993- contains tow extra optional fields with respect to
X.509 -1988-. These new fields are the issuerUniqueIdentifier and
subjectUniqueIdentifier, and they are defined to contain a generic BIT
STRING. For now on, the former field will hold the issuerCertId and the
latter the subjectCertId).
My very first purpose, when developing this idea, was to provide
certificates with the necessary information so that they express, by its
own, policy and certification path semantics. In this way, a certificate
can unambiguously be identified by means of its certificate identifiers
irrespective of names (a name can now be considered as mere descriptive
information, a pointer to a certificate holder instead of forming part of
the certificate identifier itself, etc.). The fact of introducing a
mechanism for treating certification and naming independently have brought
to me more and more benefices than I expected on the beginning. Indeed, I
am still not sure about having discovered all the advantages.
Among these advantages, by using certificate identifiers, we can develop a
clear model to state trust and connectivity between entities issued with a
certificate. In particular, the model addresses the following scenarios:
1) Hierarchical certification: complete hierarchies
2) Partial hierarchies
3) Stand-alone certification
1) Complete hierarchies
A complete hierarchy is that defined in RFC-1422 and contains a Top-level
Authority or Policy Registration Authority, several Policies Certification
Authorities endorsed by the top-level authority, several User
Certification Authorities (of different classes Organizational,
Residential, PERSONA, others) certified by PCAs, and users certified by
UCAs. In this model, multiple complete hierarchies are explicitly
permitted.
From a trustworthy point of view, a certificate issued in one of such
hierarchies is supposed to have a wider scope than other certificates
outside complete hierarchies. This does not mean that these certificates
will unconditionally be trusted by everybody, but such certificates will
normally be more trusted than other outside complete hierarchies. For
instance, the trusting scope that a user's self-signed certificate may
reach will normally be smaller than a certificate endorsed by a policy
under the IPRA. Whereas the former will be trusted in a local or direct
environment, the latter will additionally be trusted (at least) by all
users under the same policy.
2) Partial hierarchies
Partial hierarchies are those forming an incomplete hierarchy, namely;
policy sub-trees and user sub-trees. The degenerated case of incomplete
hierarchy is that of a user's self-signed certificate.
Policy sub-trees are those hierarchies which have not an explicit
endorsement from a well-known top-level authority. In this case, PCAs will
become the root of the hierarchy by unilaterally endorsement and
publication of policy statements.
In the absence of operative top-level authorities or in a initial stage of
new policies, policy sub-trees may become useful.
From a trustworthy point of view, certificates issued under a policy sub-
tree will be trusted as far as policy statements are publicly available
and accepted. In my opinion, endorsement of a policy by a top-level
authority does not imply direct acceptance of such policy by the rest of
policy sub-trees in the hierarchy, but it only supposes registry and
publicity of the policy in a wider scope. On the other hand, top-level
authorities will ease connectivity among policy sub-trees.
User hierarchies are considered stand-alone certification structures.
3) Stand-alone certification
Stand-alone structures are those created by individual initiatives and are
not certified by a PCA. This means that certificates have neither policy
nor hierarchy endorsement.
Stand-alone certification can be, for instance, user self-signed
certification (RIPEM), third-user certification (PGP) or organizational
certification (stand-alone hierarchies) without policy endorsement.
From a trustworthy point of view, stand-alone certification will normally
have a more limited scope than hierarchical structures. They will normally
be present in local environments or in scenarios where trust is derived
from direct contact.
However, these structures can be useful for the deployment of security
services in that users may initially have no need for more superior
endorsement, but it will be further when such a need appears.
* Trusting a certificate
With the described scenarios, trust on certificates will vary depending on
the certification infrastructure (hierarchical or not) under a certificate
was issued.
In particular, a self-signed certificate will generally inspire less
confidence than a third-party endorsed certificate, and this less than a
certificate endorsed under a well-known security policy. So far, the only
way a user can be noticed about the certification infrastructure related
to a certificate is by tracing such certificate along the structure
itself. Thus, a self-signed certificate is discovered because certificate
issuer and subject name are the same, a third-user endorsed certificate
because the issuer has been endorsed by the recipient (Alice has received
a message from Bob which has been certified by David in which Alice
trusts), a hierarchical certificate because the issuer has been endorsed
by a well-known policy (which may, in turn, be registered by a competent
authority).
Definitively, certification information is currently spread along the
certificate infrastructure in use. This brings to me one (two?) major
concerns:
- In order to be NOTICED about the certification conditions under which a
certificate has been issued, a user needs before to collect all
certification information. For instance, in a hierarchical scenario, three
certificates are needed in order to ascertain the policy in force. The
collection of such information may not always be possible or unique.
- Hint!: Having in mind that a certification system may wish to advance
from a stand-alone infrastructure to a hierarchical one (scaling the
system to a wider trust scope), there is not explicit way of
distinguishing old issued certificates with new certificates, unless you
change the key material (it is more or less the same issue when trying to
distinguish two different policies in a user certificate that has been
endorsed by both).
Question: Is it useful, convenient, necessary... to make clear that a
signature was made without explicit superior endorsement and that a more
recent signature (from the same user and key material) has now this
explicit superior endorsement?
I particularly think that compiling explicit certification information in
a certificate (top-level, policy and path endorsement) will benefit the
certification system, mainly because you will get i) a high degree of
freedom in naming, ii) a certificate alone conveys the useful
certification information, iii) allow to integrate different trust models
at certificate level, iv) allow to express progression of the system to
wider trust at certificate level, v) automatically give a means for
uniquely identifying certificates, ...
Table 1 contains codification values for certificate issuer and subject
certificate identifier fields (IssuerCertId and SubjectCertId) classified
in a per-entity basis. In this table:
1) A complete hierarchy is formed with entities: Top-level, PCA/H
(standing for Hierarchical PCA), UCA/H (standing for Hierarchical UCA) and
User/H (standing for Hierarchical User).
2) A policy sub-tree as partial hierarchy is formed with entities: PCA/NH
(standing for Non-complete Hierarchy being a PCA the root of a partial
hierarchy), UCA/HP (standing for UCA in partial Hierarchy from a PCA) and
User/HP (standing for a User in partial Hierarchy from a PCA).
3) A stand-alone certification hierarchy is formed with entities: UCA/NHT
(standing for Non-complete Hierarchy being a UCA the root of the stand-
alone hierarchy), UCA/NHS (standing for UCAs Subordinated to a superior
UCA in a stand-alone hierarchy) and User/HU (standing for a User in a
stand-alone hierarchy).
4) A stand-alone user is formed with entity User/NH (standing for Non-
Hierarchical User).
Diagrams of certification infrastructure:
Top-level
|
PCA/H PCA/NH
| |
UCA/H UCA/HP UCA/NHT
| | |
[UCA/H] [UCA/HP] [UCA/NHS]
| | |
User/H User/HP User/HU User/NH
1) 2) 3) 4)
A Certificate unique Identifier (CertId) has values for the top-level or
policy registration authority identifier (praId), policy identifier
(policyId) and certification path identifier (cpathId).
Table 1. Certificate representation:
IssuerCertId SubjectCertId
praId policyId cpathId praId policyId cpathId
Top-level X n
PCA/H X n Y n.n
PCA/NH Y n
UCA/H X Y n.n.*n
UCA/HP Y n.*n
UCA/NHT [Z]
UCA/NHS Z.*n
User/H X Y n.n.*n.n n.n.*n.n.n
User/HP Y n.n.*n n.n.*n.n
User/HU Z.*n Z.*n.n
User/NH [Z]
Where symbols stand for:
- X: a unique identifier for the policy registration authority identifier
(praId). For instance, in the absence of active registration authorities,
this can be the hash value of the top-level authority X500 DN.
- Y: a unique identifier for the policy identifier (policyId). This can be
the hash value of the policy statement.
- Z: a unique identifier for the entity's public component. This can be
the hash value of the entity's public component.
- [Z]: calculated identifier Z but not present in certificate, since the
certificate already contain the public component.
- n: a serial number.
- *n: none, one or more serial numbers.
In this way, by looking at a certificate alone and examining issuer and
subject CertId fields, we can exactly deduce i) the kind of entity, ii)
the certification infrastructure, and iii) the explicit certification
information.
For instance, root entities have not issuer component (Top-level, PCA/NH
and UCA/NHT). UCAs, which are not root, have not subject component, since
this can directly be derived from the issuer by appending the certificate
serial number. Hierarchical Users have both issuer and subject components
in order to declare a terminal condition.
Note that certificates for a root stand-alone CA (UCA/NHT) and for a stand-
alone User (User/NH) have not values for both issuer and subject
components. In particular, this may result in an ambiguous codification,
since we can not distinguish between them. Indeed, it has intentionally
been coded in this way because both are stand-alone structures, therefore
trust is based on a direct model and users must explicitly be aware about
what they are endorsing.
Thinking in a method for representing certificate identifiers in a more
friendly way, the following notation can be used. A printable CertId
compiles information from the issuer and subject CertId certificate
fields.
Dotted notation for CertIds and tree diagrams:
Top-Level: X.n Top-level X 0
PCA/H: X.Y.n.n | |
PCA/NH: 0.Y.n PCA Y Y
UCA/H: X.Y.n.n.*n.n | |
UCA/HP: 0.Y.n.*n.n UCA n n Z
UCA/NHT: Z | | |
UCA/NHS: Z.*n User n n n Z
User/H: X.Y.n.n.*n.n.n
User/HP: 0.Y.n.*n.n.n
User/HU: Z.*n.n
User/NH: Z
Note that the SubjectCertId can be used to unambiguously identify a
certificate, and that the pair <NAME>+<SubjectCertId> can be used to
unambiguously locate (in the sense of distribution) a certificate.
For instance:
CertId = 1422.3C5E78A6.1.1
NAME = "C=US; O=RSA Data Security Inc.; CN=Low Assurance PCA"
or
CertId = 1422.3C5E78A6.1.1
NAME = low_assurance_pca(_at_)rsa(_dot_)com
Table 2 shows how cross-certificates (for the purpose of connectivity) are
codified.
Table 2. Cross-certificates:
IssuerCertId SubjectCertId
praId policyId cpathId praId policyId cpathId
Top-level X1 n X2 n
UCA/NHT Z1 Z2
User/NH Z1 Z2
Generic X1 Y1 n.n.*n.n X2 Y2 n.n.*n.n
Cross-certificates are only used for connectivity purposes. They are
allowed for connecting i) complete hierarchies at the top-level, and ii)
stand-alone hierarchies at root level, or stand-alone users. Case ii)
represents the explicit endorsement of a entity's credential (self-signed
certificate) by other entity at the same level.
Generic cross-certification is actually not used, but it appear for
informative purposes.
Note that cross-certification at policy level is not allowed. Policy
should or should not be accepted in terms of policy statements acceptance
by UCAs. For instance, it does not make sense that a high assurance PCA
endorse a low assurance PCA by cross-certifying it. The other way around
also does not make sense.
It is up to UCAs to decide which policy is enforced in issuing
certificates. And generally, it is up to an entity to accept a policy from
which he is not endorsed. Particularly, some policies may require to
explicitly reject other policies.
Note that cross-certificates can be distinguished because they have values
in both issuer and subject fields, and there is no hierarchical
relationship between them (the subject is not beneath the issuer).
Dotted notation and diagrams for cross-certificates:
Top-Level: n.X1-X2.n Top-level X1---->X2
UCA/NHT: Z1-Z2 | |
User/NH: Z1-Z2
Generic: n.n*.n.n.Y1.X1-X2.Y2.n.n...*n.n
For instance, an introducer can certify a public component for other user
in the following way:
Cross-Certificate
IssuerName: "C=ES; O=UPC; CN=Francisco Jordan"
SubjectName: "C=ES; L=Barcelona; S=Av. Diagonal; CN=Pepito Jose"
IssuertCertId: Z1
SubjectCertId: Z2
SubjectPublicComponent: K2
Dotted notion
CertId: Z1-Z2
NAME: "C=ES; O=UPC; CN=Francisco Jordan"
which means that user with name "....CN=Francisco Jordan" and public
component K1 with hash value Z1 has certified public component K2
belonging to user "....CN=Pepito Jose" with hash value Z2.
* Certificate Validation procedure
In this model, the validation process for a certificate takes into account
(mostly at certificate level) the following issues:
- The certification infrastructure where the certificate was issued (stand-
alone or hierarchical).
- The certification information as the basis for superior endorsement.
- Explicit checking of certification hierarchy from certification
identifiers (optionally also in names).
- Preferably pull-oriented validation model, although push model is also
supported.
- Use of certificate identifiers as the basis for addressing certificates
(names are used for locate certificate holders).
For instance, for PEM processing the procedure mainly differ in that PEM
explicitly limits CA naming, forces names to be subordinated, and needs of
the full certificate chain to validate the certificate. In this proposal,
there is not explicit naming limitation or rules, and a first diagnostic
of whether the validation will or will not success is possible by only
processing the first certificate in the chain.