Re: [IETF-PKIX] account-authority digitial signature .... fyi

[Russ Housley <housley@xxxxxxxxxx>]

Lynn:

What, if anything, do you want PKIX to do to accodate your models?

Russ

At 06:52 AM 12/16/97 -0800, you wrote:
>This is public-key model that i've been working on to handle
>the "non-push" implementation for X9.59. This has been
>cross-posted to x9a10, x9f5, and spki mailing lists. X9.59 is
>designed to be used for any account-based transaction (check,
>debit, credit, etc).
>
>Three digital signature models are described; the original "offline"
>model and two newer "online" models. It is expected that the two
>"online" models become the prevailing modes of operations for much
>of electronic commerce
>
>Digital Signature Model 1:
>--------------------------
>The traditional PKI infrastructure talks about issuing certificates
>that are signed by a certificate authority which attest to the:
>     validity of the public key
>     preferably checking validity of the private key
>     possibly some identity information of the entity
>        that the certificate is issued to.
>The associated PKI-use model has an entity "digitally signing" a
>document with their private key and "pushing"
>     the transaction/document
>     the digital signature
>     a copy of their digital certificate
>to another party. The receiving party presumably will validate the
>authenticity of the digital-signature and the originator's public key
>via the contents of the associated digital certificate.  Originally
>the contents of the digital certificate was assumed to be sufficient
>such that digital signature validation could be performed without any
>additional electronic transmissions. As the methodology matured, it
>became apparent that more and more complex verification mechanisms
>were needed, if nothing else various status could have changed between
>the time that the certificate was originally manufactured and the
>current moment. Certificate revokation lists (CRLs) were one such
>development in an attempt to partially address the issue of current
>real-time certificate status in the offline verification model.
>
>Digital Signature Model 2 (or account-based PKI):
>------------------------------------------------
>This is a proposed implementation for the X9.59 framework. An
>account-holder registers their public-key (and verification of their
>private-key use) with the account authority. In a transaction the
>account-holder digitally signs a transaction and pushes the
>transaction, the digital signature, and the account number.
>Eventually the transaction arrives at the account authority and the
>digital signature is verified using the public key registered in the
>account record.  The account authority maintains the status of the
>holder's public key as part of the overall account management
>process. The transaction therefore requires neither a certificate nor
>some complex status methodology (like CRLs) since the account
>authority maintains current validity status as part of account
>management.
>This is effectively the X9.59 check and credit-card models where the
>receiving entity/merchant does a real-time authorization with the
>account issuing institution. The consumer's digital signature is
>forwarded by the merchant to the issuing institution; the issuing
>institution authenticates the digital signature using the registered
>public-key in the account record.  No signed certificate attesting to
>the validity of the public key is required since the public-key is on
>file in the account record.
>An account-authority performs the majority of the same functions
>performed by a certificate authority, but the processing costs are
>absorbed by the standard business process ... not by charging for the
>issuing of a certificate. It is possible that an account-authority
>might also wish to become a certificate authority since it potentially
>could be undertaken at less then 5% additional business costs.
>
>Digital Signature Model 3 (positive authentication):
>---------------------------------------------------
>This is actually a slight variation on #2, although it bears some
>superficial resemblance to #1. The initial designs for positive
>authentication PKI, used the credit-card authorization model to
>replace CRLs. However they kept the rest of the infrastructure; the
>originator's certificate was still pushed around with the transaction.
>The receiver validated the CA's signature on the certificate, then
>sent off a certificate status request and validated the CA's signature
>a second time on the status response (and then validated the original
>digital signature).
>Model #3 looks very much like model #2 in that the originator's
>certificate is not pushed around with the transaction. However, rather
>than sending the digital signature in the authorization request, just
>the certificate identifier (account number) is sent to the CA. The CA
>signs a status response that includes information regarding the
>real-time validity of the account along with a copy of the account's
>public key. In effect the real time status response becomes a
>mini-certificate. The entity that will act on the transaction now only
>has to verify the CA's signature on the status response (i.e.
>mini-certificate, it doesn't also have to verify the CA's signature on
>a certificate manufactured at some point in the past). It then uses
>the public-key returned in the status response to validate the
>originator's digital signature.
>Superficially this resembles digital certificate model #1 but the
>actual operation is much more like model #2. Including the account's
>public-key in the real-time status response creates, in effect, a
>mini-certificate. It also eliminates a redundant/superfluous
>validation of the CA's digital signature (on both the manufactured
>digital certificate and the real-time status responses).
>The biggest operational difference between #2 and #3 is that the
>account authority verifies the originator's digital signature in #2
>and in #3 it just returns the value of the account's public key for
>the requester to validate a digital signature.  If the requester can
>send the document or even the secure hash of the document to the
>account authority along with a copy of the digital signature, then the
>account authority can verify the digital signature. If not, the
>request just identifies the account and the mini-certificate is
>returned allowing the requester to validate the digital signature.
>The positive authentication model presents a number of revenue
>opportunities for the CA to charge for various levels of detail
>returned in real-time status responses (and/or approval levels
>associated with the transaction).
>Conclusion
>----------
>Digital signature model #1 was originally developed to allow "offline"
>verification of a digital signature. A manufactured certificate was
>pushed along with the signed document and the digital signature could
>be verified using just the contents of the certificate that was passed
>along with the document.
>Offline signature verification using a certificate manufactured
>several months in the past (and by implication relying on status that
>was several months stale) turned out to be inadequate for various
>kinds of transactions. This has led to the definition of more
>complicated processes in the certificate-push model in an attempt to
>provide more timely status and verification.
>There has also been the implicit assumption that only the certificate
>authority is performing registration services for digital signature
>processes. As the concept of digital signatures have become more
>acceptable, it has also becoming apparent that existing business
>processes (already performing account registration functions) can be
>simply extended to add public-key registration.
>Revisiting the PKI basic architecture, it became apparent that there
>were several optimizations possible if it was recognized there were
>significant numbers of online PKI operations (compared to earlier
>models that started out assuming offline PKI and later tried to graft
>online features afterwards).
>The offline validation and certificate push model is still valid for
>some types of transactions and shouldn't be precluded. However, real
>online validation (models #2 and #3) can eliminate some number of
>superfluous operations.
>It should be noted that the "offline" validation is different than the
>"offline" purchasing referred to in X9.59. X9.59 assumes that the
>consumer can be offline and transmits an order and payment
>instructions via methods like email (not requiring real-time, online
>interaction with the merchant).  In the validation process, there is
>an issue whether the merchant is also offline at the point that it
>approves the transaction.  If the merchant is offline, then it needs a
>consumer certificate to validate (and authorize) the consumer
>transaction. If the merchant is online, then either model #2 or model
>#3 is used (and it is not necessary for the consumer to push the
>certificate with the transaction). Furthermore, in the case of model
>#2, either the merchant can perform its own PKI registration function
>and/or it can rely on a financial account infrastructure to have
>implemented a PKI registration function.
>It is expected that digital signature models #2 and #3 become the
>prevalent modes of operation for at least financial transactions.
>
>Denial of service attack addenda
>--------------------------------
>There is a hypothetical case (that can be made for certificate pushing
>in the online world) which is associated with anonymous denial of
>service attacks. The existing Internet infrastructure provides
>significant opportunities for electronic terrorists to anonymously
>(and/or under assumed identity) launch denial of service attacks
>(flooding a web site with enormous number of bogus requests). These
>are undertaken with the assumption that it is nearly impossible to
>trace the source of the attack.
>One of the techniques for dealing with denial of service attacks is to
>recognize and eliminate bogus requests as soon as possible. If a
>certificate is pushed with a request then some preliminary screening
>of requests can be performed during initial processing and possibly
>eliminate some number of bogus transactions.
>The downside is that public key operations are extremely expensive;
>preliminary screening of a request using the certificate (and still
>doing the online validation later) could be more expensive than
>allowing bogus transactions through and recognizing them via the
>standard mechanism.
>Most of these are simple band-aid solutions. The real problem is that
>existing Internet backbone operation makes it simple to impersonate a
>network address. As a result it is usually very difficult to trace
>back to the originator of an electronic attack.
>