RE: German Key Usage

["Friedrichs, Paul" <friedrip@xxxxxxxxxxxx>]

Hello All,
     
     
     ______________________________ Reply Separator 
     _________________________________
     Subject: RE: German Key Usage
     Author:  Tony Bartoletti [SMTP:azb@llnl.gov]  at DISAHUB 
     Date:    8/13/98 7:50 PM
     
     
     At 05:45 PM 8/13/98 -0500, Gene Williams wrote:
     >On the surface Paul's comments seem logical, however, I'm 
     wondering why any >process which authenticates privileges and 
     access would not demand >non-repudiation??? 
     
Non-repudiation or audit? I agree with Tony that it is imperative that 
we are able to prosecute crackers, for example. But that still doesn't 
have to be "non-repudiation."
     
      If a key, which has been copied for encryption key >recovery 
     purposes, is used for digital signatures associated with I&A as 
     >well as for encryption, it seems that we're back to the basic 
     reason for not >making copies of keys used for digital signatures. 
     
I agree there is a strength argument here. And I think our X.509 
forefathers placed excessive belief in the strength of a digital 
signature absent of Tony's "continuum." I completely agree with Tony. 
Even prosecuting a break-in, one couldn't rely on an isolated I&A 
exchange when trying to send someone to prison for life. Both require 
"continua." If we believe I&A/MAC also required nonRepudiation-grade 
strength in courts of law (despite the fact that few if any session 
negotiations are captured for audit purposes), then we should not allow 
the possibility of escrowing the private key and so it should be 
separate from all privacy-related keys. 
     
Since others complain that conscious non-repudiation keys should never 
be used for automated I&A, we would find ourselves committed to at 
least three keys per person. I don't think it's worth the additional 
complexity, but if that's what the market wants, it would be the right 
answer.
     
     ..................
     
     The problem is that non-repudiation is a semantic, not a 
     syntactic. If, as Paul writes, the NR-bit is a mechanism by which 
     a CA can "promise to support non-repudiation by archiving 
     certs/CRLs" then we should call it the "caArchiveBit".
     
Any way we look at it, the assertions made in a certificate have to be 
the basis of some understanding between the CA and the relying party. 
Whether it's to mean "I promise" or "you can," if there is no 
difference, why make any assertion? 
     
     We get the mechanical component of NR by virtue of the 
     mathematics. But how many ways, in a court of law, can I still 
     arguably repudiate such a signature (or any key-usage)?  Myriad.  
     I need only convince
     a judge, or 12 jurors, that someone stole my smartcard, or I may 
     have babbled the pin-number to a roommate while talking in my 
     sleep, or who knows what else. NR is a continuum from "easy to 
     repudiate" to "difficult to repudiate".
     
I completely agree. I think I could argue my way out of any digital 
signature. Does that mean we shouldn't try to improve the "continuum"? 
Shouldn't we strive to provide a service that supports "difficult to 
repudiate"?
     
     Always, the party possessing the signing/encrypting (secret) key 
     is always free to mis-apply the key (use signing for 
     data-encryption, or vice versa) however bad an idea this might be.
     
True, we're all victims of the user's client, which may or may not 
comply with key usage.
     
     Similarly, the relying party has the power to accept or reject a 
     particular usage of a key, using a certificate as guidance.  A 
     cert may say "this key only certified for DS", but it cannot 
     assert that "there are no other certificates for this key contrary 
     to the usage prescribed here."
     
True again.
     
     As long as we limit the application of "bits" to mechanical 
     distinctions, we can limit the confusion factor. 
     
To theorists. The reason I'm suddenly jumping into the fray here is 
that I'm on the hook to support business requirements. We must strive 
to eliminate the business requirements confusion factor, not the 
X.509v3 confusion factor.
     
      As soon as we try to apply them to nebulous concepts like 
     non-repudiation, several systems removed from the signing 
     mechanics, we will have trouble.
     
And if we don't the technology is stillborn.
     
Paul