Informational A. Wheeler L. Wheeler Nov 16, 1998 Internet Public Key Infrastructure PKI Account Authority Digital Signature Infrastructure Status of this Memo Abstract This document generalizes the Internet Public Key Infrastructure to support PKI Account Authority Digital Signatures (AADS). Prior work has focused on the subset of account authorities which manufacture X.509 certificates. This document provides a generalized framework for certification authorities which may or may not choose to manufacture X.509 certificates (as part of their certification process) and/or use certificates as part of the digital signature validation process. 1. Introduction 1.1 Background A public-key digital certificate (hereinafter "certificate") binds a public-key value to a set of information that identifies the entity associated with the use of the corresponding private key. In a typical transaction, some form of electronic document or transaction is created and then digitally signed with the entity's private key. Then the electronic document, the digital signature and a copy of the certificate are combined together. It was possible to verify the validity of the digital signature by referring to the contents of the accompanying certificate. The account-authority digital signature model extends the certificate-based PKI model to support digital signature validation both with and without certificates. In its simplest form, AADS provides a framework for extending existing business processes for electronic commerce by mimicking an account signature card. Account-authority digital signature model maps directly into existing account-based validation and authentication business processes (especially in the financial industry). The registration of the public-key in the account record can be viewed as 1) a digital version of an account signature card 2) a digital version of an account's "mother's maiden name" field 3) next generation PIN authentication. PIN recording at a financial institution requires special handling since the PIN-value is used for both originating and validating electronic transactions. A public key could also be viewed as a next generation PIN since the public key can only be used for validating digital signatures (and not originating digital signatures). 1.2 Model Following is a simplified view of the architectural model assumed by the Internet PKI specifications. +---+ | A | +------------+ | c | <-------------------->| End entity | | c | Operational +------------+ | o | transactions ^ | u | and management | Management | n | transactions | transactions | t | | | | PKI users v | | -------+-------+--------+------ | | PKI management ^ ^ | | entities | | | | v | | R | +------+ | | e | <-------------- | RA | <-----+ | | p | certificate | | | | | o | publish +------+ | | | s | account no. | | | I | publish v v | t | +------------+ | o | <--------------------------| AA/CA | | r | certificate publish +------------+ | y | CRL publish ^ | | signature validation | +---+ account no. publish | Management | transactions v +-------+ | AA/CA | +-------+ Figure 1 - Internet PKI Entities 1.3 Purpose The purpose of this document is to generalize the traditional certificate-based PKI model to include the Account Authority Digital Signature model with online digital signature validation. 1.4 Scope The scope of this document is to cover the account authority digital signature features not found in other PKI models. 2. Definitions This document makes use of the following defined terms: account authority digital signature model (AADS) - a generalized PKI authority that verifies the relationship between an entity and and account. An account authority may elect to not manufacture a certificate as part of that process certificate authority digital signature model (CADS) - traditional PKI authority that manufactures a certificate that attests to the validity of some relationship between an entity (or at least the entity's public key) and one or more items of additional data. certification authority - a service that verifies the relationship between an entity (or entity's public key) and something else. trust propagation - a certification authority that provides a service for relying parties to verify some status or condition (possibly via manufactured certificates or online status service) 3. Concepts This section explains the concepts of generalizing certificate-based PKI model to account authority digital signature model. In the simplest form, an entity's public key is registered with an account-authority (in much the same way that it might be registered with a traditional certification authority). The account-authority returns an account number associated with the registration. An account-authority can operate as a traditional certification authority (and manufacture a certificate) or may choose to just return the registering account number. Note that account registration of an entity's public key maps directly into existing account-based business processes (analogous to an account signature card or recording the "mother's maiden name" in an account field). 3.1 Certificate Use In the original certificate-based digital signature validation, the combined object (electronic document, digital signature, and certificate) was assumed to be sufficient to perform the signature validation function. As the scope of PKI applications expanded it became apparent that the certificate alone might not be sufficient for validation. For one thing, the certificate might attest to a particular condition which was valid at the time of manufacture, while the application is dependent on more timely knowledge of a condition (not as it might have been some time in the past). To address the timeliness opportunity, various mechanisms have been invented like CRLs (certificate revocation lists) and OCSP (online certificate status protocol). Another characteristic that began to evolve for certificate-based digital signatures was the possible role of the certification authority as a trusted third party and the use of certificates in propagating that trust. The trust role of certificates (either in accepting trust propagation and/or in propagating trust) is viewed in the AADS model as an optional business decision, not something required of the digital signature validation PKI structure. 3.2 Simple Account Authority Operation The simplest account authority implementation performs nearly identical to the more common certification authority in registering an entity's public key. However, instead of manufacturing a signed certificate, only an account number is returned. Simple account authority validation operation combines the electronic document/transaction, the digital signature and the account number. When processing the simple AADS combined object (document/transaction, signature, account number), the account authority validates the digital signature using the public key registered for the specific account number. An application for this mode of operation is for financial institutions processing electronic payment instructions. Business for a number of years have used account records for the binding of information (especially real-time information like account balances in the financial industry). Within the context of the CADS model, certificates are a method of binding (somewhat static) information. In many cases, account-based business processes can be simply extended to include the binding of a public key (especially business processes which already include binding of authentication information like PINs, mother's maiden name, SSN, etc). In the simple financial PKI scenario, the certification authority registration of the entity's public key is the electronic business process analogy of the signature card used when opening an account. The verification of an electronic payment instruction includes, at least, digital signature validation and account balance verification. In this mode, the standard core business processes have been extended to encompass electronic PKI operation (by somewhat mimicking a signature card or other authentication operations). In the simplest AADS operation, a business decision can be made to neither accept certificate trust propagation and/or generate certificate trust propagation. Only the PKI AADS options totally under the account authority's control may be selected (which don't involve trust propagation and the issuing of certificates). There is also work on issuing of relying-party-only certificates (because of privacy and liability issues) which may contain nothing more than an account number and a public key. In the case of a financial transaction where the account record must be accessed, it can be shown that an AADS certificateless transaction is equivalent to relying-party certificate operation but saves on operational complexity and bandwidth while reducing systemic risks. 3.3 Account Authority Options An account authority can be viewed as supporting three business processes: 1) public key registration 2) digital signature validation 3) timely trust propagation status An account authority is viewed in both its role as verifying the public key association with something (like an account) as well as possibly validating digital signatures on documents or transactions transmitted to it (a financial institution might be considered a typical example). 3.3.1 Account Authority Registration In the public key registration arena, an account authority can choose: a) return just account number b) manufacture a certificate If an account authority chooses to manufacture a certificate, it can further choose from a broad spectrum of business options with regard to certification and certificate policies and practices (what is being certified and what certificate uses are supported). In the simplest case, a relying-party-only certificate may be manufactured (possibly because of privacy and/or liability issues). 3.3.2 Account Authority Validation In the validation arena, an account authority can choose to a) only support account registered public key for validation b) only support account-authority certificates for validation c) support trust propagation certificates from others for validation 3.3.2.1 Digital Signature Validation Without Certificates Some businesses may choose to operate an account-authority and do signature validation using account-based public key (rather than certificate). This may be as simple as a business decision to not rely on (trust) some other party. There may be other considerations leading to account-based signature verification: * a signed document or transaction may be transmitted over a legacy network that lacks the facilities to include a certificate in the transmission * the mechanics of contacting 3rd parties as part of digital signature validation may introduce unacceptable systemic risks (obtaining timely certificate status, verifying certification hierarchy, etc). Even the CA's certificate signing key represents an additional systemic risk. 3.3.2.2 Legacy Network Addenda Records Standard certificate-based solutions (in the past) to legacy network restrictions have been to truncate the signature validation prior to transmission. This maintains the certificate-based signature validation design but cripples end-to-end integrity (introducing additional systemic risks). Most of the financial transaction legacy networks support simple addenda records. The length restrictions on these records are typically such that they could accommodate the size of a digital signature but not the size of a certificate. A financial transaction protocol is defined that creates a virtual document that includes data elements found in a normal financial transaction record. A small number of other elements may be required in the virtual document to guarantee the integrity of the financial infrastructure. This virtual document is then signed and the document and signature is transmitted to a relying party. The relying party extracts the necessary elements from the virtual document and forms a financial transaction record. Any additional elements and the digital signature are placed in an addenda record. Both of these records are then transmitted over a financial network for execution. The receiving financial institution, receives the financial transaction and addenda record. The original virtual document is recreated from the necessary data elements. The digital signature is then verified using the public key on file for the account (aka electronic signature card). 3.3.3 Timely Trust Propagation status If an account-authority chooses to manufacture a certificate, then it can choose to provide timely status via * certificate revocation lists * online certificate status An account-authority could also choose to provide timely digital signature status (whether or not it selected to manufacture a certificate) * online account &/or digital signature status Note that the manufacturing of a certificate and the associated trust propagation represents a new business process (compared to existing business processes of account management). 3.3.4 Account Authority PKI Option Summary An account-authority can optionally choose to manufacture a certificate as part of public key registration. If it chooses to manufacture a certificate, then any of the features applicable to certification and certificate policies and practices may be chosen. It might also choose not to manufacture a certificate, just registering the public key for an account (electronic analog of signing a signature card). An account-authority can choose to validate digital signatures with or without the use of certificates (and/or decide what certificates are acceptable for signature validation). An account-authority can optionally choose to provide timely trust propagation status like certificate revocation lists, online certificate status, and/or online digital signature status. An account-authority can select which PKI options (trust propagation, certificate manufacturing, timely status, etc) to support based purely on its own business requirements. Basically an account-authority can restrict itself to existing business processes that have been extended to accept new digital form of authentication. Optionally, an account-authority can choose to get into new business process of trust propagation associated with the manufacture of certificates. 4.0 Certificates, Policies and Practices 4.1 Trust Propagation Without Certificates Much of the certification and certificate policy issues deal directly or indirectly with trust propagation. An account-authority can elect to provide trust propagation, even when not performing certificate manufacturing by providing an online digital signature status service. Relying parties are then dependent on the certification policy of the account-authority as well as to what might the online digital signature status attest to. Choosing not to manufacture a certificate eliminates any ambiguity about the nature of the trust propagation a certification/account authority wishes to support. The downside to trust propagation with simple certificate validation of digital signatures is the certification/account authority that manufactures the certificate has no knowledge of the number of uses (or the types of uses) the digital signature has been used for. Furthermore, the status of the relationship represented by the certificate may change over time (and may no longer even be valid). In the online digital signature status process, the account authority can keep track of both the number and and type of uses of the digital signature. An account authority could elect to not validate signatures in excess of some limit and/or for certain type of purposes. Another business option for an account authority would be to provide a variety of different digital signature validation services which met different specific business requirements (an example might be to scale the surcharge on validation operation proportional to liability, somewhat analogous to insurance). 4.2 Simple Authentication and Identification Taking a business example of a bank account, part of the registration process is for authentication purposes: the signature card (for later comparison), social security number and mother's maiden name (basically shared secrets). The social security or tax payer number can actually serve two separate business processes; a shared secret for authentication and (IRS) identification for reporting taxable interest. A business process for opening a financial account can include the individual supplying a public key (and some proof indicating possession of the corresponding private key). This is in place of, or in addition to other shared secrets. For interest bearing accounts, the consumer would also provide a certificate signed by the IRS containing the tax payer number. The consumer might choose to use the same (as in the IRS certificate) or different public key for registration with a financial institution. However, if there was an online IRS service, the consumer could just digitally sign their tax payer number and the bank would forward it to the IRS for authentication. Public keys are used (in place of shared secrets or physical signatures) for authentication. Transactions requiring authentication by the registering account authority, don't require certificate embedded in the transaction (since the public key is already on file for the account). The digital signature and the account record provide the necessary information to authenticate the transaction. Business processes that wish to rely on some other entity's authentication could choose to rely on a certificate (especially if there was no online authentication process). A bank might wish to rely on a IRS tax-payer-number certificate, since (without an online IRS authentication service) it might not get around to reporting taxable interest on the account for another twelve months. The evidence and authentication of a tax-payer-number certificate provides the bank an extra level of comfort regarding the tax payer number. Similarly, a consumer might wish to prescreen valid merchants by validating a bank issued certificate before proceeding with a electronic commerce transaction. The bank issued certificate may only indicate what the bank is already obligated to with respect to the merchant under existing credit card regulations. 4.2.1 What is the business This business process certificate approach is similar to that of SPKI with respect to the usefulness of globally unique distinguished names [SPKI]. However, it comes at it from a business process perspective. It differs in that the public key is an attribute (for authentication) of the certificate subject (rather than the public key being the subject and everything else attribute(s) of the key). Proposals using the public key as the subject might possibly be an adaptation of a X.509 certificate with a single name and multiple attributes. If a bank wished to sign a (single) consumer certificate that listed all of the consumers accounts; each one of the account numbers would be a "subject" or "name" of the certificate. The public key becomes the authentication attribute for that certificate. In orientations containing only a single subject, the public key becomes that subject and all the account numbers are attributes of the certificate. Single subject metaphors are also sometimes the results of row-oriented databases with single index keys (and their associated restrictions imposed by single key schemas). Is the business process PKI and management of certificates (i.e. public key bindings), where everything is attributes of that process? Conversely, is the business process something else (like bank accounts) and PKI's role is electronic authentication in connection with the (real) business process? Finally (somewhat echoing SPKI), is there a real business process for identification (sometimes confused and intertwined with the issue of globally unique distinguished name) as opposed to authentication (or in the case of bank account and interest payments, cross authentication) in support of some other (real) business process? Sometimes the identification issue is couched in terms of transition from non-electronic to digital. For example, the adding of a public key authentication to an existing account record might be viewed as simplified if a mailing address already existed in a trusted certificate and it is the same as the mailing address listed for the account. The assumption is that there are frequently used attributes (like mailing address) and that a business case can be created for an independent party binding those attributes (once) to a public key (effectively on behalf of a large number of other entities). If the attributes already assumed to be correct for an account are the same as (at least some of the) attributes in an attribute certificate, then it somewhat simplifies the process of registering a public key for authentication use with an existing account. There are really two separate business processes: 1) the mapping of an authentication public key to something (i.e. potentially matching certificate attributes against attributes in the business process, i.e. mailing address) and 2) the use of the public key for authenticating a business process transaction. In the offline certificate case between anonymous parties, this sometimes appears to be collapsed into a single process. 5. References [PKIX1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key Infrastructure, Part I: X.509 Certificate and CRL Profile", draft-ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress). [PKIX3] C. Adams, S. Farrell, "Internet Public Key Infrastructure, Part III: Certificate Management Protocols", draft-ietf-pkix-ipki3cmp-0X.txt, 1997 (work in progress). [PKIX6] C. Adams, S. Ruccherato, "Internet Public Key Infrastructure, Part VI: Notary Protocols", draft-ietf-pkix-ipki6np-0X.txt, 1997 (work in progress). [PKIXFTP] R. Housley, "Internet Public Key Infrastructure, Operational Protocols: FTP and HTTP", draft-ietf-pkix-opp-ftp-http-00.txt, September 1997. [PKIXOCS] R. Ankney, M. Myers, "Internet Public Key Infrastructure, Online Certificate Status Protocol - OCSP", draft-ietf-pkix-ocsp-02.txt, February 1998 (work in progress) [SPKI] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B Thomas, T. Ylonen, "SPKI Certificate Theory", draft-ietf-spki-cert-theory-02.txt, March 1998 (work in progress) Appendix A Digital Signed Financial Transaction Flow This is a high-level flow for a retail payment transaction. The following acronyms are used: MFI ... merchant financial institution CFI ... consumer financial institution The consumer is provided product details, merchant supported payment options, and merchant-id (possibly on a cdrom or web-page). Consumer selects items to be purchased. Consumer builds order detail document. Consumer computes hash of order detail Consumer selects payment method from supported options Consumer builds and signs financial payment object Consumer transmits order detail document and financial payment object to merchant Merchant checks contents of order detail document and verifies correct amount in financial payment object Merchant creates authorization request and financial payment addenda record and transmits to MFI MFI creates interchange authorization request and copies financial payment addenda record and transmits to CFI CFI recreates financial payment virtual document and verifies consumer's digital signature CFI returns approval or non-approval authorization response message for payment request to MFI MFI forwards the authorization response to the merchant Merchant transmits the authorization response status to the consumer in the merchant acknowledgement. In this flow, no encryption is required to preserve the integrity of the financial infrastructure. The AADS-operation is fully integrated into the financial structure and the consumer is operating with a AADS-only account number. Since this account number is only valid when used in conjunction with the consumer's digital signature, it is not necessary to cloak the number (from eavesdropping) in order to head-off fraudulent uses. Furthermore end-to-end integrity is provided. The consumer that is responsible for authorizing the payment is the one signing the transaction. The CFI responsible for executing the payment transaction is the one verifying the consumer's digital signature.