Authentication vs. binding signature, and ephemeral vs. permanent key usage

Every time I think I understand what these bits mean, someone 
shines a light in another dark corner and I see something I hadn't 
considered before.  The discussion regarding "ephemeral" signatures
has had that effect.

I'd therefore like to advance the argument that there really ought to
be two (at least) separate _services_ denoted by two separate bits,
 i.e., Authentication and Binding Signature, and that the nature of 
these services ought to be completely independent of the 
_mechanisms_ that may be used to provide them.

I'd also like to argue the difference between "digital signature" and 
"nonrepudiation" is NOT due to the difference between"ephemeral" and 
permanent/enduring/eternal, but rather a confusion between a service
and a mechanism, coupled with a confusion regarding the effect of 
certificate expiration (or revocation) upon either authentication or a 
binding signature.

I'm therefore going to argue that "nonrepudiation" should be redefined 
to say what the consequences of certificate expiration are upon either 
authentication or a binding signature.  Or better yet, since the lawyers 
would argue that a signature can always be repudiated if the use of 
force or compulsion, mental or legal incapacity, etc., can be shown, 
we should use some other term to indicate whether a digital signature 
(whether used for authentication or binding signature) is intended to 
remain in effect after the expiration of the certificate.  "Ephemeral" 
seems way too short for what might be a three year period, so I would 
suggest "enduring" for those signatures that are intended to have
lasting effect beyond the certificate expiration.

Finally, I will argue that the "digital signature" _mechanism_ bit should be 
used to differentiate between a mechanism that can be used to encrypt
information for secrecy vs. a mechanism that cannot be used to conceal
information, but can only authenticate information.  This distinction is 
crucially
important from an export control perspective, for high grade cryptography (long 
keys and/or strong algorithms) may be acceptable from an export (or 
import/usage)
perspective if and only if it is used for authentication, but not if it is 
capable of 
being used for information concealment.

This has nothing to do with key escrow per se, at least necessarily, although
some regimes might require key escrow for all data encryption keys (and 
probably key encryption keys as well), or they might require key escrow for 
key lengths and/or algorithm types that are beyond a certain "strength".

Key escrow does, however, significantly dilute the confidence of digital 
signatures
from a technical nonrepudiation standpoint. It also dilutes the confidence that 
the 
originator might have when sending an encrypted message to someone!

So I would argue that we need a key usage bit that says "accessible by a third 
party". (Key escrow means one particular scheme to those in that business, 
whereas
key recovery means something slightly different, and there are additional 
schemes
involving key derivation from escrowed keys that have to be considered. A simple
phrase like "key escrow" is not sufficiently broad.)

I'm not entirely sure that I understand the ISO notion of a _service_,
vs. a mechanism, perhaps because a service it sounds a little bit 
too much like X.400, and I wonder and worry about who the service 
provider is.

But I do agree that "authentication" ought to be a service,
even without some kind of an institutionalized service provider. The 
service in this case ought to be independent of the mechanism,
whether it is based on password validation, biometric identification, 
Kerberos tickets, asymmetric cryptography, a hashed MAC, or
whatever.  Of course, not all of those authentication mechanisms would
necessarily be appropriate for inclusion in a digital signature certificate,
but that in itself is not sufficient justification to deprecate those 
mechanisms.
Just as sure as we say that something isn't needed, a protocol like IKE
will come along and use it.

In many cases, authentication is used to provide confirmation of identity
for access control purposes, but I would assert that it can also be used to 
provide a cryptographic assurance of the integrity of an stored object and its 
originator, just as encryption provides cryptographic assurance of the 
confidentiality of the object and the recipient.

In other words, I ought to be able to use a digital signature _mechanism_
to cryptographically assure and authenticate the integrity of anything 
from a random doodle, to a draft work in progress, to a scurrilous rumor that I
am passing on just because it is funny.

Now it happens that one of the more common usages of authentication
is for the duration of a session, and it is therefore understandable that 
the notion of authentication as being "ephemeral" could have crept
in.  But even in the case of SSL or IPSEC, it is possible to have a 
permanent connection that might endure for years. Likewise, a digitally
signed draft will probably be of little or no interest after a few weeks or 
months, but that shouldn't mean that the authentication automatically
becomes null and void a day later.

On the other hand, a "Binding Signature"  ought to be another service, 
and it probably ought to be independent of the mechanism(s) used to 
provide it.  

(As an aside, within the US legal community there has been an extensive 
debate/wrangle about the desirability of defining digital (or more correctly 
electronic) signatures in a "technology-neutral" manner, and most of the 
recent statutes, including the US contributions to UNCITRAL, are moving
in that direction. This causes me considerable unease, because in some 
cases the soundness of the technical underpinnings of some schemes seem
rather questionable. But it appears that I am losing that argument.)

To my way of thinking, the primary difference between the authentication 
service and the binding signature service lies in the INTENT of the signer 
to be bound or obligated by the semantic _content_ of the object being 
signed, whereas I would claim that the authentication service is essentially 
_independent_ of the semantic content.

Now, having said that, does that mean that there is no distinction between 
an ephemeral (tactical), vs. enduring (strategic) authentication and/or 
binding signature?  No, it does not.

In particular, I can imagine circumstances under which a binding signature
might very well apply to the entire contents of a session, e.g., a home banking
transaction.

But it is important to understand that the length of time during which 
either the authentication or the binding signature is associated with 
an object, whether a session or a more conventional stored data object
has nothing whatsoever to do with the INTENT of the signer to be bound
(legally obligated by) the signed object.

That doesn't mean that there is no difference, of course.

In particular, one obvious difference is what assumptions are to apply 
after the expiration of the CA's responsibility to continue to report the 
status of a particular certificate, i.e., after the (public key) certificate
validity period has expired.

>From the standpoint of the user, a public/private key pair that never expires
carries with it a substantial and enduring liability, since it is possible that
key might have been compromised covertly.

>From the standpoint of both the originator and the relying party, if there 
is some possibility that a document will be contested at some time after the 
expiration of the certificate validity period, then a substantial amount of 
additional
effort must be invested into doing all of the things that are loosely and 
imprecisely
lumped under "nonrepudiation", including some form of trusted time-stamp and/or
third party certification of the validity of the certificate chain at the time 
the object 
was signed.

On the other hand, if both the originator and all possible relying parties had 
a 
common understanding that a binding signature was valid and enforceable
for a specified period of time, and was null and void, at least in terms of the 
digital signature mechanism after that point in time, then the uncertainty of 
whether
or not timestamping the message and the entire certificate chain by a third or
fourth party would be necessary could be avoided completely. 

In summary, I would suggest the following new key usage bits:

1.  Authentication -- a service

2.  Binding signature -- a service

3.  Enduring -- an indication of the validity of the authentication or binding 
signature
after the certificate validity interval. This should replace the current 
"nonrepudiation"
bit, which should be deprecated.

4.  Accessible by a third party -- i.e., subject to key escrow, key recovery, 
etc., 
whether by one's employer, a trusted third party, and/or the government 
directly.

5.  Ideally, the "digital signature" mechanism bit must be exclusive of any 
other usage.  
But if it is used in combination with other bits, it will may mean that the key 
will
NOT be exempt from key escrow or weakened cryptography requirements that
may be imposed by various regimes.

Bob

>
>
>>>> Hans Nilsson <hans.nilsson@xxxxxxxx> 08/13 9:03 AM >>>
>Blake,
>
>Now that I have looked up "ephemeral" in a dictionary (it means short-lived,
>"only for a day", just like those beautiful insects), I think that the
>definitions a) and b) are good.
>
>However, I can then not understand why the document later states that "When
>the nonRepudiation bit is set, the digitalSignature bit shall always be set"
>
>Of course, one should be allowed to specify that a key ONLY should be used
>for long-term signatures (non-repudiation) and not anything else. When both
>bits are set, as required in 15782, it means that the key always may be used
>for ephemeral data also.
>
>And the statement above is also in conflict with the new table 8, where ANY
>combination is allowed for the two bits in combinations 1 and 2 (and I can
>see no difference between combination 1 and 2!)
>
>I think this should be changed in 15782 (and consequently in the German
>spec), by 
>- deleting the sentence above
>- allowing just one bit in each of combinations 1 and 2 (digSignature and
>nonRepudiation respectively)
>
>Hans
>
>+-------------------------------------------------------------+
>+ For information about the cert-talk mailing list, including +
>+ archives and how to subscribe and unsubscribe, visit:       +
>+          http://mail.structuredarts.com/cert-talk           +
>+-------------------------------------------------------------+


Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@xxxxxxxxxx

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home."