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

Bob,

I can see your point for authentication vs. binding signature, but since
we're basing this work on X.509, I see no reason for discussing new key
usage elements unless someone is interested in generated a defect report
for X.509, and I don't recommend that.

I've put forth the recommendation to use digitalSignature usage for
ephemeral, session-oriented authentication applications, but I truly
wonder if such an application exists.  I thought it might apply to
SSL/TLS-like protocols, but PKIX-1 defines extended key usages for TLS. 
I wouldn't be surprised to see new extended key usages for the IPSec
protocols.  Is there an application that would look for a
digitalSignature bit as defined by the profiles?

Dave S.

Bob Jueneman wrote:
> 
> 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."

-- 
David Simonetti, Booz·Allen & Hamilton Inc.