RE: German Key Usage

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

Hi Aram,
     
     Aram Perez wrote:
     
     Paul Friedrichs wrote:
     >
     >     Aram Perez:
     >
     >     Security 101: Any key (whether symmetric or asymmetric) should
     >     have one and only one use/purpose. Typically the uses are: 1) Key

     >     Exchange (or key encrypting), 2) Data encryption, and 3)
Signature 
     >     (or binding).
     >
     >This is dogma.
     
     One's man's dogma is another man's good security practice ;-)
     
I admit, there is a place for dogma. A wink doesn't make it good dogma. But
it 
might be.
     
     >
     >     Just because you can do something technically does not mean that 
     >     you should do it. There are plenty of security reasons why you
     >     should not use one key for more than one purpose. 
     >
     >Reason(s) must be the basis of keyUsage, not dogma. What's the 
     >difference between 1) and 2), above? Why should they be distinguished?
     
     What's the difference between 1), 2) and 3) for asymmetric algorithms?
In 
     all three cases you are encrypting something: 1) a key, 2) a data
stream, 
     and 3) a digest.
     
The huge difference between #3 and the first two is the one-way function 
performed before the encryption. 

Why must we have so many encipherment keyUsages? Especially if we are saying
the
standard addresses syntax, but not semantics, and that the various CP cert 
profiles should address which key usage bits mean what, keyUsage appears to 
provide about as much interoperability as garage door openers which use 2^n 
switch combinations to prevent interoperability.
     
     >
     >     Non-repudiation is more of a "business/legal" concept than a
     >     technical one. Asymmetric signatures can provide the property of 
     >     non-repudiation only if you are 100% assured that the signer is
     >     the only entity that has access to the private key. I'm anxiously

     >     waiting for the first lawsuit related to the "non-repudiation" of

     >     a business transaction (performed with a private key stored on a 
     >     file).
     >
     >I agree. That's why *nonRepudiation* keys must remain separate form 
     >anything that might be escrowed. This is not violated if 
     >digitalSignature keys which are not asserted to support nonRepudiation

     >are escrowed, for example.
     
     Why would you ever escrow any signature key? I personally have never
heard 
     of any proposal/plan/law/etc to escrow signature keys. My understanding
of 
     why the US Government and law enforcement want key escrow is to decrypt

     information, not to be able to regenerate a signature.
     
I am not proposing we go out of our way to escrow signature keys. I
completely 
agree it is not preferable. I'm wondering how to limit the number of
keys/certs 
each entity requires, and reduce the 2^n keyUsage possibilities to make 
interoperability more likely.
     
     I will re-state: "There are plenty of security reasons why you should
not 
     use one key for more than one purpose." 
     
Sorry, I just haven't seen any on this list. Individual conflicts in
keyUsage 
*must* be identified - I completely agree! - but I'm not convinced anyone
has 
logically argued such an absolute assertion as this. All I ever read are 
restatements of this quote. What does "purpose" mean? By "purpose" do we
mean 
"keyUsage"? Or do we mean application/business requirement? If our ancestors
had
handed us thirty five keyUsage bits, would this claim still be made? 

What are the few fundamental key purposes? Perhaps, for end entities,  1) 
Encryption, 2) Authentication/MAC, and 3) Non-repudiation? Certainly, 1&3
can't 
be shared. Some state 1&2 should not be shared because of encryption laws.
Some 
state they don't want 2&3 shared because of the conscious/unconscious uses.
Are 
three keys/certs the way to go? Is separation between 2 & 3 worth the cost,
or 
might we get (back) down to two keys/certs?
     
     (and not just dogma).
     
Maybe.

Regards,

     Paul