Online Certificate Status Checking in
Financial Transactions:
The Case for Re-issuance
Barbara Fox and Brian LaMacchia
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA
{bfox, bal}@microsoft.com
Abstract. High-value financial transactions underwrite the need
for a relying party to check the status of a digital certificate in real time.
In this paper, we propose a simple mechanism for online certificate status
checking that is particularly well suited to the closed public key
infrastructures that characterize financial networks. We further demonstrate how
persistent evidence of this status checking request/response becomes a valuable
by-product. In financial systems, “transaction receipts” naturally accumulate
and by doing so, they encapsulate the entire lifecycle of a single transaction.
Keywords: public key infrastructure, online certificate status
checking, certificate re-issuance, high-value financial transactions, risk
management
1. Introduction
The financial community has identified the need for a relying party to “real-time” check the validity of evidence supporting a high-value transaction. For example, merchants routinely “authorize” credit cards as a part of a transaction. As these transactions increasingly take place on-line over the Internet, however, and become entirely dependent on digital signatures and supporting evidence in the form of PKI elements, the mechanics of authorization must change.
The first attempt at defining an electronic authorization scheme suitable for Web-based credit card transactions was the Visa/MasterCard Secure Electronic Transactions (“SET” [SET]) suite of protocols. The SET model was limited to a Web-based front-end to legacy authorization systems. On the back-end, a SET transaction is virtually indistinguishable from one that originates as face-to-face or via a telephone order.
The next step towards creating a completely web-based analog for authorizations is currently under development by the PKIX working group in the IETF. The X.509 and PKIX standards provide suitable mechanisms for off-line or cached authorization operations and certificate revocation lists (CRLs). However, because CRLs are created with specific lifetimes (possibly unbounded) they are not suitable for real-time status checks. For a particular high-value[1] transaction, the relying party’s policy concerning that transaction is likely to require a near-instantaneous statement of the validity of the public key/certificate in question; a CRL issued two weeks prior is effectively worthless as evidence of the key’s current status. Thus, additional mechanisms are needed within the public key infrastructure (PKI) to provide real-time information.
The most prominent technology proposed for this type of verification within the PKIX infrastructure is the “Online Certificate Status Checking Protocol” [OCSP], and it is on track to become an Internet standard. OCSP has two important characteristics: first, OCSP depends upon the emergence of its own three-tier (Client - Certificate Authority – Designated Responder) infrastructure, and second, OCSP defines a new set of message formats extending beyond those contained in the base PKIX standard (PKIX Part 1).
In this paper, we propose a simple alternative to OCSP for online certificate status checking. Moreover, we argue that requirements for authorizing digitally-signed transactions should be independent of the underlying form of public key infrastructure in which they occur.[2] These requirements must minimally include a “freshness” check on the evidence submitted in support of the transaction (which could be a digital certificate). As a by-product of doing the check itself, persistent evidence that the check was made must also be created.
It should be understood that OCSP is used merely as an example of current practice in the field of real-time status checking for digital evidence. Nevertheless, OCSP provides an important yardstick for comparing and contrasting and new mechanisms. The chief infrastructure difference between this proposal and OCSP is that our approach is targeted to serving the functional and policy requirements of closed PKIs, which we believe will host the majority of high-value financial transactions. “Closed” in our context means only that the parties’ rights and obligations are defined by mutual agreement or contract. For example, the Automotive Network Exchange (ANX), is a closed PKI comprised of more than 1,200 trading partners.
2. Motivation
Figure 1 below depicts a typical high-value electronic financial transaction using public key credentials. There are three parties of interest: the “end entity” (seller of the financial transaction), the “relying party” (the buyer of the financial transaction) and a “certification authority” (“CA”). The role of the CA is to attest to the binding between the end entity and some public/private key pair. Initially, before any particular transaction can occur, the end entity needs to obtain proof of ownership of a public/private key pair that he will use electronically to sign the transaction. The end entity generates a public/private key pair (or uses one previously generated) and submits a certification request to the CA (step 1). The CA processes the request and, if the request satisfies the CA’s certificate issuance policy, the CA responds by issuing a certificate to the end entity (step 2).
Figure 1: A typical financial transaction using public-key credentials
Now, for a particular transaction the seller sends the transaction to the potential buyer along with some evidence (step 3). The evidence will be used by the buyer to determine (a) whether the seller is who he claims to be, and possibly (b) that the seller has the right to participate in the transaction (e.g. current ownership of the transaction). The certificate previously obtained may be sufficient evidence on its own; it is more likely, though, that certificate will be used in conjunction with other signed statements contained within the transaction itself. Having received the transaction and supporting evidence, the relying party not must make a policy decision and determine whether the submitted evidence satisfies his own acceptance policy for the transaction.
As part of this evaluation of evidence, the relying party requires a real-time status check on the certificate issued by the CA—that is, is the binding in the certificate still valid? The buyer thus makes a real-time status request of the issuing CA[3] for confirmation of the validity of the certificate (step 4). The CA issues its status response (step 5) attesting to the current validity of the subject certificate. The status information is then combined with the transaction, the certificate and other submitted evidence by the relying party to make his policy determination. The result of that decision (i.e. whether the transaction will be bought and any receipts if it is) is returned to the seller in step 6.
Our concerns in this paper are with the protocols and signed
statements used to form the status request in step 4, the status response in
step 5, and the transaction response in step 6. The chief technical difference between OCSP and
our proposal is that we issue a new X.509 certificate in step 5 as the response
to a status inquiry. While it may seem obvious to simply issue a new
certificate, OCSP goes out of its way to avoid doing so. In fact, OCSP crafts a
response that looks not surprisingly like a CRL. Here is the structure of a single OCSP status response:
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT
GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT
Extensions OPTIONAL
}
CertStatus ::= CHOICE {
good [0] IMPLICIT
NULL,
revoked [1] IMPLICIT
RevokedInfo,
unknown [2] IMPLICIT
UnknownInfo
}
Within a SingleResponse, the certID identifies a particular certificate
and the certStatus is the returned assertion about that certificate – one of
“good,” “revoked,” or “unknown.” This
assertion is then signed by the responder, creating a digitally-signed
statement about the referenced certificate.
(OCSP, unlike our proposal, does not explicitly permit status requests
concerning only a public/private key pair.)
As such, the OCSP response itself is semantically equivalent to a
certificate[4], but is
written in a new format. The only explanation for this distinction is that the
OCSP authors could attach one value to a certificate and another value to its
real-time status. This is economics,
not technology.
What is unavoidable, though, is that the digitally-signed statement
containing status information is itself an independent
assertion and, as such, carries liability for its signer. In typical
financial applications, other new criteria, such as current credit-worthiness,
are brought into the transaction as a result of a status check and the role of
the signer is unambiguous: the signer owns the risk.
“Ownership” as the result of issuing a status response becomes literally
correct when we replace the word risk
with transaction. Transactions are the commodity that is
bought and sold in every financial market.
In the credit card case, for example, the card merely bootstraps a
transaction. When the merchant
authorizes a sale, he sells the transaction to his bank at a discount. If the bank is also the card issuer, then it
does not need to re-sell the transaction; it may settle directly with the
merchant and cardholder. If the bank is
not the issuer of the presented card, then it sells the transaction to a
settlement agent at another discount.
In each case, a sale represents a shift of risk from the seller to the
buyer for which the buyer creates a
receipt. During the life of a
transaction, what matters is the issuer’s signature on an assertion that turns
it into a receipt, not the signature on the card.
Figure 2 below overlays Figure 1 with the flow of policy evaluation, confirmation, and the generation of receipts. Again, there are three parties of interest: the “end entity” (seller of the financial transaction), the “relying party” (the buyer of the financial transaction) and a “certification authority” (“CA”). Steps 1 through 3 are essentially the same: (1) The end entity generates a public/private key pair and submits a certification request to the CA (2) The CA processes the request and, if the request satisfies the CA’s certificate issuance policy, the CA responds by issuing a certificate to the end entity and (3) In the context of a particular transaction the seller sends the transaction to the potential buyer along with some evidence. The important distinction here is that the action of the relying party breaks down into two policy-driven steps.
Figure 2: Policy evaluation, confirmation and receipts
In step 3, the relying party’s external interface receives the transaction and supporting evidence and uses it to formulate a trust management question (step 4), “Is my policy satisfied?” Policy evaluation may include a number of real-time queries:
(a) a real-time status check on the submitted certificate (step 5),
(b) an application-specific real-time check, such as communication with a bank to determine current credit-worthiness, and
(c) a evaluation of locally-held policy-related information, such as the buyer’s prior transaction history with this particular seller.
The relying party’s policy evaluation engine combines externally gathered status information with local policy and generates an acceptance or denial result. In either case, a statement of the decision is returned to the seller (step 7).
There is a second important concept at work here that is often
overlooked: receipts outlive
transactions. Long after a
transaction has run to completion and terminated, the receipts involved in that
transaction are still “live” because they provide evidence of what took
place. Should the transaction be
repudiated at a later date, for example, it is the signed receipts that will be
required to prove or refute the claim.
By having buyers issue certificates as receipts for transactions, we
replicate this financial model in the PKI domain. Furthermore, because the infrastructure for issuing certificates
already exists, it is not only feasible but also simple to leverage existing
software to create, forward, evaluate and store them.
3. Mechanisms
For lack of a better term, we call our proposed on-line status mechanism “certificate re-issuance.” The idea behind certificate re-issuance is deceptively simple:
Any useful response to a real-time query concerning the
status of a public key is necessarily a (digitally-signed) statement about that
public key. Similarly, the response to
a query concerning the status of a certificate for a public key is necessarily
a (digitally-signed) statement concerning that certificate, which is itself a
(digitally-signed) statement about a public key. In both cases, the response can be expressed completely as yet
another (digitally-signed) statement about a public key. That
is, the response to a real-time query is just another certificate.
In an X.509v3/PKIX-based PKI, we make statements about a public key by issuing certificates that contain both the subject public key and the semantic content of the statement we wish to make about it. In a real-time status query, our goal is typically to ask one of two questions: (a) has some particular subject public key been compromised, or (b) is some particular statement about a public key no longer valid? The response to (a) is a statement about the validity of a public key, which is clearly semantically equivalent to a certificate issued for that key. The response to (b) is a statement about a certificate. While we could choose to use some other syntax to embody such a statement (e.g. a PKCS#7 [PKCS7] or CMS [CMS] signed message), it is possible to use standard X.509v3 certificate syntax and doing so yields some nice additional properties.
Consider a typical PKI-based scenario involving a high-value transaction. Let Alice and Bob be respectively the requesting and relying party in a two-party, high-value transaction. As part of the transaction request, Alice presents a set of credentials (evidence) that she hopes will help convince Bob to perform the requested transaction. These credentials include one or more certificates ci that relate to Alice’s public key. Without loss of generality, assume that c0, c1, …, cn is a single certificate chain and that Alice’s public key is the subject of cn.
Bob’s policy for the requested transaction will accept the certificate chain c0,…,cn as proof that Alice’s public key is authorized to make the transaction request. However, due to the specifics of the transaction Bob’s policy additionally requires real-time proof that Alice’s key has not been compromised in order for the transaction to be processed. So, Bob asks Irwin, the issuer of certificate cn, whether the binding attested to within cn is still valid. (Note that it was Irwin who validated the name-key binding between Alice and her public key in the first place.)
In response to this request, Irwin issues a second certificate, cn’, which restates the binding between Alice’s name (or other identifying information) and her public key but with semantics that reflect the binding’s state at the current time. For example, cn’ might have a very short validity period covering only the duration of Bob’s real-time request, where cn may be valid for a year or more. Assuming that cn’ was signed by Irwin with the same public key as was used to sign cn, Bob may validate cn’ using the same certificate chain that validates cn. That is, if c0, c1,…, cn-1, cn is a cryptographically-valid certificate chain, then so is c0, c1, …, cn-1, cn’. The evidence gathered in c0,…,cn-1 that validates Irwin’s public key with respect to cn also validates that key with respect to cn’.
The two certificates cn and cn’ do have different semantics, so we need to distinguish them in some fashion. This may be easily achieved through the use of standards X.509v3 certificate extensions. For the inbound request for real-time status information there are a few standards-based syntax options, all of which are approximately equal in function and expressive capabilities.
3.1. The Response
We first detail the response to a real-time status check rather than the request itself because in our particular case the response is the more interesting of the two messages. By viewing a real-time status request as a certificate request, we accomplish two significant tasks missing from other proposed standards such as OCSP. First, we leverage existing syntax, message formats and infrastructure as opposed to creating new messages out of whole cloth. Second, we keep our risk-related semantics consistent; responding to a real-time status check is yet another risk transference, just like certificate issuance.
There are compelling practical and technical reasons to avoid creating new syntax for real-time status requests and responses, the most important one being that “we have too many different messages types already.” In order to construct PKI message components you need two things: a standard format for making digitally-signed statements and some agreements on semantic meaning for some forms of statements. We have a standard format for making digitally-signed statements: the PKCS#7/CMS family of message types [PKCS7, CMS]. Anyone who has labored in the X.509v3/PKIX realm knows that as these two message types are arbitrarily extensible they are more than sufficient for expressing any desired semantics concerning signed statements. This includes certificates and certificate requests, of course. Had PKCS#7 come first we might have avoided X.509v3 entirely and simply made certificates be a special type of PKCS#7 message. (Similarly, PKCS#10 certificate requests could easily have been based on PKCS#7 too.)
However, since X.509v3 did come first we have lots of infrastructure for dealing with both certificates and PKCS#7 messages, with instances of the former normally thought of as providing the evidence for accepting instances of the latter. This distinction is not really important however, since X.509v3 certificates are themselves extensible and fully capable of making statements about keys and other certificates. Thus X.509v3 is a perfectly reasonable and practical standard for on-line status responses; we need only define the semantics of an extension or two to provide the new functionality.
Assume that an on-line status responder receives a request to provide current information on the key contained with certificate cn. (We view requests for status information concerning cn itself versus the public key contained within cn identically as the only difference in the two responses will be a minor semantic distinction indicated in one extension.) Section 3.2 proposes some mechanisms for delivering the actual request to the responder; for our immediate purposes the particular mechanism is not important, only that the responder receives the request and accurately identifies it as a “freshness check” on cn. If the responder can confirm that the subject certificate has not been revoked and/or wishes to apply new policy, he then issues cn’, a new certificate, which differs from cn as follows:
1. The validity period of cn’ is narrowed to the window in which this freshness certificate is valid. (This period is likely to be significantly shorter than the validity period of cn itself, and in practical terms is probably less than one day in duration.)
2. The responder adds to cn a new extension indicating that it is a freshness assertion about a public key or another certificate. The presence of the extension itself (which is identified by its own OID) can server as notice that the certificate is a response to a status check. The data contained in the extension, which we call the ResponseSubject, must necessarily reference the object for which status was requested: a public key or a certificate. The easiest way to do that is to use a modified form of the AuthorityKeyIdentifier data type defined in PKIX Part 1, Section 4.2.1.1:
ResponseSubject ::=
SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
certIdentifier [1] CertIdentifier OPTIONAL,
certIssuer [2] GeneralNames OPTIONAL,
certSerialNumber [3] CertificateSerialNumber OPTIONAL,
}
KeyIdentifier ::=
OCTET STRING
CertIdentifier ::=
SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
certHash CertHash
}
CertHash ::= OCTET
STRING
A ResponseSubject may be one of three types: a reference to a particular public key, a reference to a particular certificate via hash, or a reference to an issuer/serial-number pair (which should only correspond to a single certificate). (We expect that these three options will be used exclusively: a ResponseSubject is likely to contain exactly one of keyIdentifier, certIdentifier and the pair (certIssuer, certSerialNumber).) Note that since the keyIdenfier is presumed to correspond to a SubjectKeyIdentifier contained within certificate cn there is no need to identify a hash algorithm for it. For the CertIdentifier structure we need a certificate hash (algorithm and hash function output) to uniquely identifier the certificate that is the subject of the response.
3. Additionally, the responder may choose to add other extensions to further qualify the status statement being made in the certificate.
In the failure case the responder has a couple of options. First, the responder could simply fail to return a response, although this is not particularly useful to the requesting party. More likely, the responder will return some other signed statement including information concerning why the status check failed. A third possibility is to require that certificates issued in response to an on-line status check contain two extensions; one containing the ResponseSubject information described above, and a second (call it ResponseStatus for lack of a better term) that explicitly contains success/failure information. A requesting party’s policy could easily check such explicit information as part of its evaluation of cn’.
3.2. The Request
Having defined the response message in our real-time status protocol, we now turn to the syntax for requesting a real-time status certificate. The request message is not as interesting technically as its sole purpose is to convey, from requestor to responder, the key or certificate for which status information is desired. Even restricting our set of available protocols to those defined by the IETF PKIX and S/MIME working groups, there are still a number of possible methods to perform this task. We outline three of these below; any of them would suffice.
The first possibility for delivering the request message is to view the request as a variant of the enrollment process for a new key pair, since the outcome of both processes is the issuance of a certificate. The de facto industry standard for requesting a certificate for a public/private key pair is defined by the PKCS#10 protocol [PKCS10]; however, PKCS#10 messages are self-signed to provide proof-of-possession of the corresponding private key. Since we assume that in the case of real-time status checking the requesting party is not normally the same entity as that possessing the key pair in question, a standard PKCS#10 message is not sufficient.
The second standards-based possibility for real-time status checking is to model the request as a variant of the certificate renewal enrollment process. The difference between certificate renewal and enrollment for a new key pair is that in renewal one or more certificates have already been issued against the key pair in question. These certificates may be submitted to the issuing authority as evidence that a new certificate should be issued. In our case, if the requestor wants status information concerning a particular certificate c, the message delivered to the responder may be exactly that particular certificate. If the requestor wants status information concerning a particular public/private key pair, a certificate containing the public component may again be used as the message to the responder. Note that in the latter case some additional information must be sent in addition to indicate that a response about the key is desired and not a response about the certificate carrying the key.
A third possibility for the request message format, and perhaps the most satisfying of the trio, is simply to leverage the existing extensibility in the proposed CMS-based certificate enrollment protocol [CMC]. In CMC, the Full Enrollment Request message is a signed CMS with a payload of zero or more commands and enrollment requests. We can use the ResponseSubject structure defined above as the value in an OID-value pair, and include any referenced certificates in the CertificateSet portion of a SignedData CMS content payload. That is, the body of the CMS SignedData message becomes simply a data structure of the form:
SEQUENCE OF
SEQUENCE {
id-realtime-status-request // an OBJECT IDENTIFIER
requestSubject // a ResponseSubject
}
}
where ResponseSubject is as defined above and provides a reference either to a particular public/private key pair (by referencing the key identifier of a public key), or to a particular certificate (either by hash or by an (issuer name, serial number) pair). The type of request being made (key versus certificate) is implicit in the choice of identifier[5].
In summary, both the request and response messages in our proposed real-time status protocol easily fit within the bounds of current PKI infrastructures. The request message can be built on top of the PKCS#10, X.509v3 or CMS standards (CMS being the most convenient and straightforward of the three). The response message is an X.509v3 certificate. Obviously, there is a clear advantage to extending current standards as opposed to inventing new message types as existing PKI clients and certificate servers will require minimal modifications to take advantage of our proposed protocol.
4. Economics
Our proposal differs from the OCSP model in one more significant way: the pricing model for digitally-signed statements. OCSP pre-supposes a particular pricing model that attaches high cost (and high liability) to the issuance of every certificate. At the same time, OCSP also presumes that there exists a relatively small community of qualified certificate issuers and designated status responders. We believe this is a narrow view; there is no a priori reason to so restrict the universe of possible issuers of signed statements. Ultimately risk lies not with the issuer of a “global certificate” that provides some particular long-term binding (such as an “identity certificate” binding some name-related information to a key pair), but rather with the numerous parties that issue receipts.
The premise that individual certificates are relatively scarce and relatively expensive also pre-supposes that acceptance policy is dictated to third parties by the certificate issuer. That is certainly not the case in financial transactions; acceptance policy is strictly a policy of the party buying the risk. This is simply an extension of the principles of decentralized trust management [BFL, CFLRS] to the financial realm. In this model, when a transaction is purchased and the buyer issues a certificate as a receipt, the receipt simultaneously represents two distinct assertions. First, of course, the receipt denotes the transfer of ownership. Second, and more subtlety, the receipt represents proof that the seller submitted sufficient evidence to the buyer to satisfy the buyer’s policy. The receipt, therefore, is proof of a two-way commitment between seller and buyer.
Finally, notice what happens when the buyer of a transaction, after issuing a receipt, turns around and re-sells it. Buyer becomes seller, and the receipt issued previously is now a piece of evidence submitted to the new buyer proving that the old buyer applied his own policy at the time he purchased the transaction. In fact, the set of receipts generated by every transfer of the transaction forms a digitally-signed chain of evidence binding not only every step of the transaction but also every policy application that happened along the way. In practice these policy assertions are explicitly detailed in the contractual relationships between parties that govern rights of repudiation[6] around transactions, but they are not explicitly bound into the transactions themselves.
Figure 3 illustrates how accumulated signed receipts, generated as part of the process of selling and re-selling a single transaction, encapsulate the transaction’s history. Initially, party A holds transaction T and receipt CertA (the receipt describes how A came to hold the transaction in the first place). He proposes to sell the transaction to party B (step 1) and sends B the transaction along with his certificate and other supporting evidence. B evaluates the evidence to see that it satisfies his policy and issues a receipt—CertB—as proof that his policy was satisfied (step 2). The new receipt is returned to party A in step 3 and the transaction between A and B concludes. B now holds transaction T, certificate CertA (which references T) and certificate CertB (which references both T and CertA).
Figure 3: Accumulated receipts encapsulate transaction history
Now B decides to re-sell the transaction to party C. As above, B first sends the transaction to the proposed buyer along with his supporting evidence (step 4). Notice that the evidence submitted by B includes both the evidence submitted by A to B when B bought the transaction in the first place as well as the receipt B issued showing that B’s acceptance policy was satisfied. Party C performs his own acceptance policy evaluation in step 5 and issues certificate CertC as proof of acceptance of the transaction. This new receipt, which references T, CertA and CertB, is returned to B (step 6) to complete the resale of the transaction. A further resale of the transaction from C to D is shown in steps 7-9, resulting in D issuing receipt CertD.
At the conclusion of the three sales of transaction T (step 10), party D holds the transaction and four receipts—CertA, CertB, CertC and CertD. Together, these receipts detail exactly how transaction T moved among the four parties, what policy decisions were made along the way, and the commitments made by each party in the process. Even after the transaction terminates and no longer exists, the receipts persist and continue to provide evidence.
5. Conclusions
The need for real-time
status information in closed PKIs for financial transactions is clear; what is
dubious is the need for new infrastructure to convey such information. We have shown above that is not only
possible but preferable, from technical and economic perspectives, to use reuse
the existing certificate issuance mechanisms and infrastructure. Digitally-signed status information about a
certificate is itself the semantic equivalent of a certificate; we should treat
it as such.
There is one final (yet quite compelling) argument to leverage certificate (in lieu of new non-certificate-based) infrastructures for real-time status information, and that is the infant (but growing) body of international law surrounding digital signatures and certificates. Only now are we beginning the process of creating the legislative underpinnings for certificates to have legal effect, and legal effect is an absolute requirement for the application of digital signatures and certificates to financial transactions. It is not at all clear that a new message type, with new syntax and semantics, would automatically fall within the legal frameworks currently being constructed. Why, absent a solid technical reason to do so, take that chance?
6. References
[BFL] M. Blaze, J. Feigenbaum, and J. Lacy, "Decentralized Trust Management," in Proceedings of the 1996 IEEE Symposium on Security and Privacy, pp. 164-173.
[CFLRS] Yang-Hua Chu, Joan Feigenbaum, Brian LaMacchia, Paul Resnick and Martin Strauss, “REFEREE: Trust Management for Web Applications,” Proceedings of the Sixth International World Wide Web Conference, Santa Clara, CA, April 1997.
[CMC] PKIX Working Group, Internet Engineering Task Force, “Certificate Management Messages over CMS,” M. Myers, X. Liu, B. Fox, J. Weinstein, eds., work in progress. (Draft as of March 1999 available from http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-03.txt.)
[CMS] S/MIME Working Group, Internet Engineering Task Force, "Cryptographic Message Syntax," R. Housley, ed., work in progress. (Draft as of April 1999 available from http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-13.txt.)
[CRMF] RFC 2511, PKIX Working Group, Internet Engineering Task Force, “Certificate Request Message Format,” M. Myers, C. Adams, D. Solo, D. Kemp, eds., March 1999. (Available from http://info.internet.isi.edu/in-notes/rfc/files/rfc2511.txt.)
[DSIG] World Wide Web Consortium Digital Signature Initiative. (Information available from http://www.w3.org/DSig/Overview.html.)
[FL] Barbara Fox and Brian LaMacchia, “Certificate Revocation: Mechanics and Meaning,” in Proceedings of Financial Cryptography ‘98, Lecture Notes in Computer Science 1465, New York: Springer-Verlag, 1998.
[OCSP] PKIX Working Group, Internet Engineering Task Force, “Online Certificate Status Protocol - OCSP,” M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, eds., work in progress. (Draft as of March 1999 available from http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-08.txt.)
[PKCS7] RFC 2315, Network Working Group, Internet Engineering Task Force, “PKCS #7: Cryptographic Message Syntax v1.5,” B. Kaliski, ed., March 1998. (Available from http://info.internet.isi.edu/in-notes/rfc/files/rfc2315.txt.)
[PKCS10] RFC 2314, Network Working Group, Internet Engineering Task Force, “PKCS #10: Certification Request Syntax v1.5,” B. Kaliski, ed., March 1998. (Available from http://info.internet.isi.edu/in-notes/rfc/files/rfc2314.txt.)
[PKIX] RFC 2459, PKIX Working Group, Internet Engineering Task Force. "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile," R. Housley, W. Ford, W. Polk, D. Solo, eds., January 1999. (Available from http://info.internet.isi.edu/in-notes/rfc/files/rfc2459.txt).
[SET] Secure Electronic Transaction protocol. (Available from http://www.setco.org/.)
[X509] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 December, 1996.