Re: Invalidity Dates

[Juergen Walter <walter@xxxxxx>]

Michael,

I would like to get more clarity about your bussiness model.

The certificate holder sends a revocation request to the CA. Hence, the
CA revoke his certificate. The next CRL  will contain the the adequate
CRL entry. I would expect that the _revocationDate_ is not earlier than
the date when the CA was receiving the revocation request. A different
practise would lead to weak systems. So, I have a confusion. How do you
define retroactive revocations? 

The CA may include the _invalidityDate_ in the issued CRL. What does it
mean? How does the relying party know that? Here is the potential for
lawyers (I´m not a lawyer). Nevertheless, I agree that this is a
"real-world" model. So, it may appropriate to certain communities.

There exists a second scenario related to retroactive revocation. The
certificate holder sends a revocation request to the CA. As a result,
the CA generates a CRL which includes the _reasonCode_
_certificateHold_. Again, the _revocationDate_ is not earlier than the
date, when the CA was receiving the revocation request. The heavy
machinery of the CA works behind the scenes. The CA may need time for
validating the authorization of the revocation request. Later, the CA
changes the _reasonCode_ from _certificateHold_ to _keyCompromise_, but
the _revocationDate_ remains unchanged.

I think, that both the _invalidityDate_  and _certificateHold_ are
needed in real world implementations. But, the following question is
still left open. How does the relying party know that?

Juergen

Mike Smith wrote:
> 
> Protection of the private key is the responsibility of the key owner.  If we build systems that shift that responsibility to someone else, then the value of the system is weakened.
> 
> If, as in this "real world" example, we use the credit card model of repudiation and indemnity (the credit card company takes the loss), then the value of PKI to ascertain identity is gone.  If we use a "cash" model instead (i.e., a thief stole $3,000 from your home while on vacation) then ther risks are known and the value of storing cash is accepted.
> 
> Retroactive revocation has its place in cryptography, especially with encryption and national security.  Retroactive revocation of identity certs is a bad business model.
> 
> When you shift the responsibility for the $3,000 in purchases, to whom do you suggest the responsibility be shifted?  The vendor?  The CA?  In your model, it seems to be the vendor.  The card issuer backs the vendor with a loss reserve and insurance.  The equivalent in your credit card model is again the CA.
> 
> So, in systems that allow retroactive revocation of identity certificates should we also then require some sort of aggregate or per item assurance value?  There would be a revenue stream here, so this is not our of line.  Several years ago we were wrestling with the meaning and infrastructure to support these "reliance limits" without the industry finding a place for them.
> 
> This is business, so, eventually, all of these repudiable losses are passed back to the customer.  How much should a certificate owner then, be expected to pay for a certificate that includes the cost of these potential losses?
> 
> Going back to the example of credit cards, the use of the card has annual charges, per transaction costs, and ongoing revenue (interest accruals and minimums).  these costs reflect the loss reserves, operating costs, etc.
> 
> if the certifcate is on a smart card that is issued by a credit card vendor, then I could see the repudiability model that you have used actually working, since the authentication methods would be better than what they already do.
> 
> This credit model is vastly different than one in which a family member uses the parents' identity card to create a new will to bring forward many years later when the original card holder is not around to repudiate it, but that is yet another business situation.  In this case, a retroactive revocation (didn't this use to be called a "compromised key list"?) may be of value.
> 
> So, there are cases where it does make sense from a busines perspective to allow retroactive revocations and some where the business infrastructure would need to be created to support retroactive revocation.
> 
> michael
>