Subject: "Authentication" and "Signature" bits...

From: Carlisle Adams <[email-masked]>
Date: Wed, 8 May 2002 13:24:32 -0400

Hi Dave,

> ----------
> From: 	David P. Kemp[SMTP:[email-masked]]
> Sent: 	Wednesday, May 08, 2002 10:49 AM
> To: 	[email-masked]
> Cc: 	'500 list (E-mail)'
> Subject: 	Re: Meaning of Non-repudiation
> 
> Bill,
> 
> I have no problem with X.509 and PKIX following Trevor's approach.
> Deprecate (using the strongest possible terms) the existing KeyUsage
> OID, and define a new KeyUsage OID identical to the old one except
> that bits 0 and 1 are replaced by nonceSign and dataSign.
 
Separating authentication and signature seems somewhat attractive on a first
glance, but I would personally be very reluctant to pursue this.  There are
three reasons for this.  The first is fairly simple and perhaps of minor
significance:  because authentication in this context is accomplished
through a signature (e.g., signing a random challenge), this doesn't "feel"
like a different key usage to me.  Both bits tell the relying party that it
can use the public key in this certificate to verify a signature.

The second reason is of slightly higher significance:  it is not always
clear when someone is signing with intent and when someone is
authenticating.  Dean Adams (no relation :-) recently sent the following
examples.

	In the first case, we are using a digital signature technical
capability to authenticate ourselves, much as we have done in the past with
passwords.  The real action that we are undertaking is authentication - the
fact it is accomplished via a digital signature mechanism is interesting to
cryptographers but not necessariliy to systems administrators, business
managers and the like.
	 
	In the second case, we are putting our name on a communication,
transaction or document for a variety of reasons (as we do in real life with
real signatures) - perhaps to indicate approval of some action (that the
transaction should go ahead, or that the contents of this document or
communication are accepted or formally issued by me), or as in the case of a
written memo from the CEO to all staff - that the contents actually come
from the the CEO.

The very last example he gave (that the contents actually come from the CEO)
was very clearly put in the "digital signature" category.  But to me, this
is data origin authentication, pure and simple.  So, if there were two
certificates, one with an authentication bit set and the other with a DS bit
set, which one should the CEO use?  Whichever he picks will be rejected by
either Dean or me when we go to verify this message.

The third reason is the most fundamental and so, to me, is the most
significant.  One of the main reasons we've had so much trouble
distinguishing between the DS bit and the NR bit is that it requires the
relying party (as well as the sender) to understand the nature of the data
that is signed.  "Is this just 'ordinary' data, or is it 'special' in some
way?"  Making this distinction can be very difficult (perhaps impossible?)
for relying party software; humans often need to be involved.  But
distinguishing between data that has been signed for the purpose of
authentication and data that has been signed for any other purpose can also
be very difficult (perhaps impossible?) for relying party software.  If I
send a random challenge and receive back that challenge signed, then of
course I know what the data is.  But what other relying party software
anywhere in the world will be able to tell if this data is a random string
or a meaningful message encoded in some way?  What software can tell the
difference between an e-mail signed purely for data origin authentication
and one signed to signify that the sender agrees with the content?

I contend that, in the general case, trying to make a distinction (in
standards specifications and in products) between an A bit and a DS bit will
be no easier than trying to make a distinction between an NR bit and a DS
bit.  Consequently, we will find ourselves no further ahead if we deprecate
the current key usage extension and create a new one that begins with A and
DS instead.

My vote is solidly in favour of retaining the current extension.  The DS bit
is, I think, clear:  "the public key in this certificate can be used to
verify signatures on any data except certificates or CRLs (which are easy to
recognize, so there's no confusion)".  The NR bit could be deprecated, or
could be given the interpretation suggested by Bill Burr (the CA attests
that it has never had access to the corresponding private key).  I
personally prefer Bill's interpretation.  I think it is very clear, even in
the situation that Stefan raised (whether the keys were produced on the
smart card, or produced in a separate box and injected onto the card, the CA
itself did not have access to the private key and so can still validly set
this bit).  It is something concrete and explicit that the CA can say in a
certificate, and it can certainly support non-repudiation in accordance with
other policies and procedures.  The only possible drawback with this
interpretation is that it is in no sense a "key usage", but the NR bit has
never really been that, so we haven't lost anything.  Furthermore, as Bill
suggested, this narrower interpretation is highly unlikely to break any
existing software.  So I can't think of a single reason not to use this
interpretation.

Carlisle.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 May 2002 14:07:10 -0400

Carlisle:
 
You make persuasive arguments in favor of existing implementation.  
 
But, on technical grounds, there is a difference between signing a
challenge and signing to some contents that you want to provide digital
signatures for.  We have this distinction for certificate and CRL and
what we have proposed is meaningful and useful without getting into all
the legal mumbo-jumbo.

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]] 
Sent: Wednesday, May 08, 2002 1:25 PM
To: 'David P. Kemp'
Cc: '500 list (E-mail)'; [email-masked]
Subject: "Authentication" and "Signature" bits...

Hi Dave, 

	---------- 

	Bill, 

	I have no problem with X.509 and PKIX following Trevor's
approach. 
Deprecate (using the strongest possible terms) the existing KeyUsage 
OID, and define a new KeyUsage OID identical to the old one except 
that bits 0 and 1 are replaced by nonceSign and dataSign. 

Separating authentication and signature seems somewhat attractive on a
first glance, but I would personally be very reluctant to pursue this.
There are three reasons for this.  The first is fairly simple and
perhaps of minor significance:  because authentication in this context
is accomplished through a signature (e.g., signing a random challenge),
this doesn't "feel" like a different key usage to me.  Both bits tell
the relying party that it can use the public key in this certificate to
verify a signature.

	In the first case, we are using a digital signature technical
capability to authenticate ourselves, much as we have done in the past
with passwords.  The real action that we are undertaking is
authentication - the fact it is accomplished via a digital signature
mechanism is interesting to cryptographers but not necessariliy to
systems administrators, business managers and the like.

In the second case, we are putting our name on a communication,
transaction or document for a variety of reasons (as we do in real life
with real signatures) - perhaps to indicate approval of some action
(that the transaction should go ahead, or that the contents of this
document or communication are accepted or formally issued by me), or as
in the case of a written memo from the CEO to all staff - that the
contents actually come from the the CEO.

The very last example he gave (that the contents actually come from the
CEO) was very clearly put in the "digital signature" category.  But to
me, this is data origin authentication, pure and simple.  So, if there
were two certificates, one with an authentication bit set and the other
with a DS bit set, which one should the CEO use?  Whichever he picks
will be rejected by either Dean or me when we go to verify this message.

The third reason is the most fundamental and so, to me, is the most
significant.  One of the main reasons we've had so much trouble
distinguishing between the DS bit and the NR bit is that it requires the
relying party (as well as the sender) to understand the nature of the
data that is signed.  "Is this just 'ordinary' data, or is it 'special'
in some way?"  Making this distinction can be very difficult (perhaps
impossible?) for relying party software; humans often need to be
involved.  But distinguishing between data that has been signed for the
purpose of authentication and data that has been signed for any other
purpose can also be very difficult (perhaps impossible?) for relying
party software.  If I send a random challenge and receive back that
challenge signed, then of course I know what the data is.  But what
other relying party software anywhere in the world will be able to tell
if this data is a random string or a meaningful message encoded in some
way?  What software can tell the difference between an e-mail signed
purely for data origin authentication and one signed to signify that the
sender agrees with the content?

I contend that, in the general case, trying to make a distinction (in
standards specifications and in products) between an A bit and a DS bit
will be no easier than trying to make a distinction between an NR bit
and a DS bit.  Consequently, we will find ourselves no further ahead if
we deprecate the current key usage extension and create a new one that
begins with A and DS instead.

My vote is solidly in favour of retaining the current extension.  The DS
bit is, I think, clear:  "the public key in this certificate can be used
to verify signatures on any data except certificates or CRLs (which are
easy to recognize, so there's no confusion)".  The NR bit could be
deprecated, or could be given the interpretation suggested by Bill Burr
(the CA attests that it has never had access to the corresponding
private key).  I personally prefer Bill's interpretation.  I think it is
very clear, even in the situation that Stefan raised (whether the keys
were produced on the smart card, or produced in a separate box and
injected onto the card, the CA itself did not have access to the private
key and so can still validly set this bit).  It is something concrete
and explicit that the CA can say in a certificate, and it can certainly
support non-repudiation in accordance with other policies and
procedures.  The only possible drawback with this interpretation is that
it is in no sense a "key usage", but the NR bit has never really been
that, so we haven't lost anything.  Furthermore, as Bill suggested, this
narrower interpretation is highly unlikely to break any existing
software.  So I can't think of a single reason not to use this
interpretation.

Carlisle.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 10 May 2002 12:09:09 +0200

> the relying party that it can use the public key in this certificate to 

Am I the only one who is scared to use the very same private key 
for signing orders and client authentication? Think about a web 
server initiating some action with your private key by serving a 
banner ad via HTTP/SSL.

Another issue with authentication certs is privacy.

Ciao, Michael.