ANSI X9F1 is currently developing a set of public key cryptography
standards for the financial services industry (banking and credit cards
in particular). There has been a lot of discussion on these sorts of
trust issues, and, in particular, how/whether to bind trust levels into
certificates (similar to PGP). This is particularly important since there
will be several types of authentication domains, with different levels of
trust or assurance in each. E.g., wholesale funds transfer systems will
typically involve a set of banks in a (relatively) low-volume, high-value
environment, while bankcard systems involve a large number of users in a
high-volume, low-value environment. The wholesale environment typically
contains "users" which are actually banks (i.e. organizations), and a
complex set of procedures is defined for them to obtain certificates In
the retail (bankcard) environment, certificates might be issued to users
who are customers of (rather than members of) the issuing organization,
and the procedures for obtaining a certificate will be arguably less secure
(e.g. issuance by mail rather than in person).
Some of the approaches we have discussed (not all of which are meant to be
included in this set of standards) are:
1. Centralized v. Decentralized Models
The PEM model of trusting a single TLCA (in each domain) was not felt to be
appropriate. In general, we do not want to impose a hierarchy within each
domain. (E.g., the first implementation will likely involve the large money
banks who are members of the NY Clearing House, who will just cross-certify
each other.) If a hierarchical model is used in a domain, the X.509 model
in which users trust (and are given the uncertified public key of) their
issuing CAs, which in turn certify their superior CAs, was though to be more
appropriate. In this model, a certification path is constructed from one
user through the "least common ancestor" CA to another user; this minimizes
damage from compromise of a CA at the top of the hierarchy, since any paths
which are "below" that CA (i.e. the users are "close" to one another in the
hierarchy), are (theoretically) not affected by the compromise.
2. Trust Attributes
We have defined an extension to the X.509 certificate to contain useful
attributes (it is issued at the same time as the PK certificate, by the
same CA, and contains the same issuer and serial number). CA certificates
might contain an attribute indicating their liability in case of a key
compromise or other breach of security; user certificates may contain binding
information which indicates the method of delivery of the certification
request, and the method the CA used to identify the user. Additionally, a
user certificate might indicate a limit on the transaction value which can
be issued using the certificate. The limited "vocabulary" of financial
messages makes it easier to formalize these attributes than in a generalized
application like PEM. (E.g. transactions typically carry a "transaction
value" field which would be checked, in the example above, against the limit
in a user's certificate.) It would seem reasonable, when issuing a cross
certificate to a CA in another domain, to include these types of attributes,
so (as a hypothetical example) a wholesale CA could cross certify a retail CA
to allow (user) transfers up to $10,000.
3. Multiple Signatures
For extremely high value transactions, it might be desirable to require
multiple CA signatures on a certificate. (Each CA signature would be issued
with a different private key, from a different cryptographic facility. This
in turn implies each CA has multiple public key certificates (or trusted
public keys). Building on the previous paragraph, a certificate might then
indicate, besides some transaction limit, a set of additional users whose
(co)signatures are required for a transaction signed by that certificate's
private key to be considered valid. The list structure can be made fairly
complex to allow quorums, weighting ("one president, two VP's, or three
directors"), etc. The cryptographic message syntax defined in RSADSI's
PKCS #7 forms a good basis for this, since it allows multiple (possibly
nested) signatures with per-signer sets of authenticated and unauthenticated
attributes.
Regards,
Rich