-A Method for Fast Revocation of Public Key Certificates and Security Capabilities-

	The authors propose a fast revocation method. If a key is compromised the owner 
should not be able to:
·	Decrypt past or present encrypted data
·	Generate digital signatures (however prior signed documents should still be valid)
·	Authenticate himself
	The paper argues that current systems do not provide fast revocation and propose 
SEM architecture. 

SEM architecture:
*****************
	The architecture includes Semi-trusted mediator. To sign/decrypt a message, one 
should get a message specific token from SEM. It is not possible to use/generate private 
key without the token. Revocation occurs when SEM does not generate tokens for that 
particular user any more.

	It is based on mediated-RSA. The private key is split into two parts using 
threshold RSA. One part belongs to user; the other part belongs to SEM. Neither of them can 
compute the private key by themselves.(In m-RSA the CA computes both the public and private 
key of the user, instead of the user himself.)

	Decryption/signing is done according to threshold RSA - which also gives the user 
the capability to verify SEM.

	SEM can be implemented using either a stateful/stateless model. In the stateful 
model SEM stores its corresponding half key for each user and user certificate. In 
stateless model, user provides this information in each request.

Benefits: 
=========
*Simplified signature validation: If a signature can be generated, this shows it is still 
 valid. Current techniques require a trusted time-stamping service for signature 
 verification.
*Enabling revocation in legacy systems. If the system does not have certificate 
 verification capabilities.

Performance:
===========
	The experiments showed that the performance of SEM architecture is comparable to 
RSA without CRT. (Neither the user nor SEM knows factorization of modulus, so the 
architecture is not compared with RSA with CRT.)

Comparison with current techniques:
===================================
	Current techniques require a trusted time-stamping mechanism, which SEM 
architecture does not require. For example, using CRL method, the verifiers each time must 
validate user certificate, by downloading long certificate revocation lists. (In this 
system this is done by only SEM) However SEM architecture is not geared towards global 
Internet.

Pros:
*****
(by Kevin Cernekee)
* A SEM server is a much less attractive target than a CA; diffusion of
  privilege is often a good thing.

* Outside the user's organization, no software changes are required; the use
  of SEM is transparent to the outside world.

* In many cases, the SEM system is a superior replacement for a trusted
  timestamper and revocation lists.

* Since nobody really uses certificate revocation in the first place, SEM
  provides a higher level of assurance than usual that users of the PKI are
  authorized; "it's better than what we have".

* SEM enforces recovation in real time; it is proactive, rather than
  reactive.

* SEM probably does not introduce a single point of failure with regard to
  the compromise of signatures or secret data; it does not require access to
  plaintext or users' private keys.

(by Suvda Myagmar)
* SEM architecture is transparent to peer users. Interaction with SEM
  during encryption and decryption is fully managed by user's email reader
  and does not require any intervention on user's part. To those who want to
  encrypt data or verify signature, the mediated RSA used by SEM appears
  indistinguishable from standard RSA.

* Simpler binding semantics: to validate a signature, a verifier need only
  verify the signature itself whereas existing techniques must also verify
  that certificate was valid at the time the signature was issued. Because of
  this simpler binding semantics, SEM has no need for tursted time service.

* SEM enables revocation in legacy systems that use old RSA. Often, sych
  systems have no certificate validation capabilities meaning they don't
  check certificate revocation status. SEM provides certificate revocation
  without any change to the verification process in these legacy systems.

* The authors implemented the entire SEM architecture and provided
  performance results. They also built a plug-in for Eudora client enabling
  users to send signed email.

Cons:
*****
(by Kevin Cernekee)

* What size organization would benefit from SEM? When is it inappropriate to
  have a CA online to check certificates, but appropriate to have SEM
  servers? How big or small is this niche?

* A trusted timestamping service may still prove useful for some
 applications, since a SEM doesn't appear to provide the user with any
 indication of when a cryptographic transaction takes place - it only
 vouches for the fact that the transaction took place when the key was not
 revoked.

* If a trusted timestamper is compromised and the time of the compromise is
 known, the damage can easily be assessed by looking at the timestamps
 produced. If a SEM server is compromised at a known time, the timestamps
 of the clients must be trusted to determine which signatures are invalid.
 This makes damage control more difficult.

* The CA becomes a bigger target because of the fact that it knows private
 keys, at least for a short time. So not only can the CA operators
 impersonate users; they can also intercept their users' past and future
 communications. How much do you trust your sysadmin?

* The current CRL system is inadequate; the authors should have discussed it
 earlier in the paper so that things would have flowed better.

Discussion:
***********
1.The authors do not mention the real performance gain by making life easier for verifiers 
  and difficult for signers.
2.SEM is a single point of failure. However replication of SEM is also not desirable. 
  The paper does not address this problem, and mainly states that their design is not 
  scalable.
3.Launching an attack that disables the communication between system administrator and SEM 
  would disable SEM learning about a revoked user. So fast revocation may not be always 
  possible.
4.The system requires SEM to be always online. If SEM goes down, it will not be possible to 
  sign/decrypt.

Voting Results:
***************
Strong reject: 1
Weak reject: 4
Weak accept: 11