RE: RE: Key Usage in ISO 15782

[Blake Greenlee <blake.greenlee@xxxxxxxxxxxxxxx>]

Dear Folks:

In U.S. financial industry standards we never use the same key to sign or
compute a MAC and to encrypt. Our practice is to keep the two processes
orthogonal.

Also, "encrypting for authentication" is not allowed in any standard.

Blake

-----Original Message-----
From:	Mike Smith [mailto:mfsmith@zionsbank.com]
Sent:	Thursday, August 13, 1998 6:45 PM
To:	stefan@accurata.se; simonetti_david@bah.com; scottg@ftm.disa.mil;
blake.greenlee@internetmci.com
Cc:	hans.nilsson@ausys.se; blake.greenlee@greenlee.com; ietf-pkix@imc.org;
cert-talk@structuredarts.com
Subject:	Re: RE: Key Usage in ISO 15782

I hope that the discussions about using digital signatures for
authentication purposes are actually refering to a digital signature and not
an encrypted nonce using the private signing key a la a transport security
mechanism.  The financial services positions usually do include an actual
digital signature with encrypted hash of a known object using the signing
key to sign the object used as part of the authentication scheme.  Kind of a
"here, sign this" request, not a "here, encrypt this".

I agree that the assumption can be made that, if the owner of a bound public
key encrypts something with their private corresponding key, then the person
using the public decryption key can have high assurance that the person
bound to that public key is who they said they were (depending on the level
and type of authentication used by the issuing CA).

I (in the financial industry) have problems with my customers using the
digital signature keys to encrypt objects directly, since we (most likely)
issued them for digital signatures and not encryption.  To me, its like
using a credit card to open a latched door.  It would work and one could
assume that the user is the bonified holder of the card - but that is not
its purpose, so should not be encouraged.

michael



>>> "Scott, Greg" <scottg@ftm.disa.mil> 08/13 12:19 PM >>>
Blake,

Thanks for giving us a chance to comment.  The use of these key usage bits
keeps coming up.  What follows is how the 15782 text confuses me, and some
suggestions what to do about it:

   "a)    digitalSignature: for verifying digitally signed ephemeral data
          for the purpose of entity authentication;"

The above would seem clearer if written:

   "a)    digitalSignature: for verifying a digital signature that
          authenticates an entity; "

To me authentication is well understood to be an immediate act.  Using an
adjective like "ephemeral," a word most English speakers have to go to the
dictionary for, is unnecessary.

   "Absent conflicting business requirements, this bit should always be set
   for digital signature certificates."

I'm not sure what this is saying.  Is it recommended that this bit always
be set in entity certificates?  Some on the lists have argued that use of
the non-repudiation should be a conscious choice of the user, is that what
"Absent conflicting business requirements," refers to?  How is this
sentence related to the Valid Combinations in Table 8?  I recommend its
deletion.

   "When the public key is used only to validate the authenticity and
   integrity of signed data (exclusive of certificates and CRLs), then only
   digitalSignature shall be set.  When the public key is used for this
   purpose, no other key usage may be set. This is illustrated as
   Combination 1 in Table 8."

The text and table 8 seem in conflict.  Table 8 tells me that to
authenticate (combination 1) I can use the DS bit, the NR bit, or both
bits.  The text says only the DS bit can be used.  I'd change the table to
reflect the text.  A dot in the DS row, and a "x" in the NR row.

   "In financial applications, a digital signature, together with
   appropriate business controls and agreements, may provide the service of
   non repudiation."

Is this supporting some kind financial industry legacy system?  Is it
intended for a standalone financial network?  (Don't want to be transacting
those big bucks where just us folks can get to em.)  It just seems to me
that if the certificate is going to be carrying the key usage bit string
any way, they could enable the NR bit like everyone else.

   When the public key supports the non-repudiation service, then the
   nonRepudiation bit shall be set., and no others may be set.  This is
   illustrated as Combination 2 in Table 8.  When the nonRepudiation bit is
   set, the digitalSignature bit shall always be set.  This combination
   provides a cryptographic separation between the function of signing data
   and the function of signing certificates and CRLs.

The text and the table don't seem to agree.  The first and third sentence
of the paragraph don't agree.  The first sentence tells me that to
establish a NR service, use the NR bit alone, the table should have a black
dot in the NR row, "x" in all other rows.  The table tells me that I can
provide non-repudiation service with the DS bit, the NR bit, or both.  The
third sentence tells me that to provide NR service, both the DS and NR bits
need to be set, i.e. black dots in both the DS and NR rows.

I interpret the fourth sentence as saying combination 2 exists because
combination 6 exists.  Is this correct?

Most of what I've gotten off the lists is that DS bit is a mechanism, while
the NR bit is a service.  This implies that the third sentence is the
correct way to go.  However,

   Some communities may want to use a certificate for both signature
   applications.  While both bits are allowed to be set, there are
   possibilities of an attack, hence the practice of setting both bits
   should be strongly discouraged.

So the first sentence of the previous paragraph is correct?  If so, it would

also follow that authentication was inherent in the non-repudiation bit.  Or

does this say some would want to use a single certificate to cover both
Combinations 1 and 2.  Is that the meaning of the "A" in the DS and NR rows?

If you had combination 2 with both bits enabled wouldn't that serve the same

purpose?

Well as you can see I'm easily confused.  For some reason the metaphor of
putting 10 lbs. in a 1 lb. bag keeps coming to mind.

I hope some of what I suggest helps.  I'm off on a two week vacation now,
but
I'll be interested to see how this has played out in my absence.

R/s Greg