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

From: Sharon Boeyen <[email-masked]>
Date: Fri, 10 May 2002 09:52:07 -0400

I'd like to try to bring the discussion back full circle and separate what I
believe are two distinct issues.
 
Issue 1: The current text that describes the digital signature and non
repudiation bits in X.509 have caused confusion and a request was made to
separate the description of digital signature from that for non-repudiation
and to clarify the meaning of the non-repudiation bit in the keyUsage
extension.
 
Issue 2: Some people would like a way to be able indicate that one key
should be used for authentication and another for signing docs (I know I'm
oversimplifying it).
 
I do not believe that we can or even should attempt to address issue 2 as
part of the solution to issue 1. I agree with Trevor that making this change
to the semantics of the bits is not backward compatible and we cannot do
that with keeping the same OID for the keyUsage extension. 
 
The keyUsage extension is in wide use today and I firmly believe we should
not do anything that would cause most deployed environments to break. I
believe that replacing the current 2 bits with the proposed new bits would
do so. The digital signature bit is widely used today to sign all sorts of
objects including all of those mentioned in this whole debate. In some cases
it is used for challenge/response authentication, in others it is used for
data origin authentication and integrity. The certificate that used to
verify my digital signature on signed emails AND the certificate that is
used by me for online banking with my bank both have the digital signature
bit set. We should not do anything that would render such implementations
non-conformant. 
 
To address issue 1 I believe we should, as Stefan originally requested,
separate the description of digital signature from non repudiation for the
bits and try to clarify the role of the non-repudiation bit if that is
possible. However, fundamentally it is the non-repudiation bit and the other
is the digital signature bit. They are not authentication and data signing
bits, never were and never should be.
 
To address issue 2, I'm not yet convinced that X.509, or PKIX really need
this separation. However, if there is a requirement, I see this more along
the lines of the APPLICATION of keys that we currently define through the
extended key usage extension. I would not want to see the current keyUsage
extension replaced in favor of this new flavor. Rather, leave the current
extension with its original semantics (just clarify them) and address this
other aspect through some other mechanism, if required at all. 
 
From my own standpoint, I'd prefer to focus on issue 1 first, as that is the
one that raised to the X.509 group as a potential defect in that standard.
 
From a process standpoint re X.509 I wanted to let folks know that Hoyt and
I do plan to discuss the whole set of messages that have been flowing on the
X.500, PKIX and ABA lists on this topic and then decide what, if anything,
we should propose be done in X.509. However because of our overlapping
vacation schedule, you won't be hearing that from us until the end of the
month. 
 
Cheers,
Sharon

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 10 May 2002 13:42:23 -0400

Sharon:
 
I commend you for a good and succinct summary.
 
The two issues are intertwined in the sense that the only authentication
and digital signature are the only two meaningful distinctions between
the two bits.  NR is a slippery slope.  That has been the most common
comment on this thread.
 
I think saying that making what crypto operation is performed on the
data is changing the semantics, is calling the proposal exactly what it
is NOT.
 
Just the way there is a separate bit for certSign and cRLSign, we have
separate bits for signing data and challenges.
 
Granted this may break backward compatibility, but whether it does or
not and to what degree it does, the vendors have not provided any data
as to which of the four combinations breaks the backward compatibility.
 
FYI, Bill Burr's suggestion while a prudent one and probably backward
compatible with the implementations, is the one that changes the
semantics of the extension.  Please read the definition of the extension
and also note that all the other bits except NR are enforced by the
client and not the CA.
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Boeyen
Sent: Friday, May 10, 2002 9:52 AM
To: '500 list (E-mail)'; [email-masked]
Cc: Trevor Freeman (E-mail); Stefan Santeeson (E-mail)
Subject: RE: "Authentication" and "Signature" bits...

I'd like to try to bring the discussion back full circle and separate
what I believe are two distinct issues.
 
Issue 1: The current text that describes the digital signature and non
repudiation bits in X.509 have caused confusion and a request was made
to separate the description of digital signature from that for
non-repudiation and to clarify the meaning of the non-repudiation bit in
the keyUsage extension.
 
Issue 2: Some people would like a way to be able indicate that one key
should be used for authentication and another for signing docs (I know
I'm oversimplifying it).
 
I do not believe that we can or even should attempt to address issue 2
as part of the solution to issue 1. I agree with Trevor that making this
change to the semantics of the bits is not backward compatible and we
cannot do that with keeping the same OID for the keyUsage extension. 
 
The keyUsage extension is in wide use today and I firmly believe we
should not do anything that would cause most deployed environments to
break. I believe that replacing the current 2 bits with the proposed new
bits would do so. The digital signature bit is widely used today to sign
all sorts of objects including all of those mentioned in this whole
debate. In some cases it is used for challenge/response authentication,
in others it is used for data origin authentication and integrity. The
certificate that used to verify my digital signature on signed emails
AND the certificate that is used by me for online banking with my bank
both have the digital signature bit set. We should not do anything that
would render such implementations non-conformant. 
 
To address issue 1 I believe we should, as Stefan originally requested,
separate the description of digital signature from non repudiation for
the bits and try to clarify the role of the non-repudiation bit if that
is possible. However, fundamentally it is the non-repudiation bit and
the other is the digital signature bit. They are not authentication and
data signing bits, never were and never should be.
 
To address issue 2, I'm not yet convinced that X.509, or PKIX really
need this separation. However, if there is a requirement, I see this
more along the lines of the APPLICATION of keys that we currently define
through the extended key usage extension. I would not want to see the
current keyUsage extension replaced in favor of this new flavor. Rather,
leave the current extension with its original semantics (just clarify
them) and address this other aspect through some other mechanism, if
required at all. 
 
From my own standpoint, I'd prefer to focus on issue 1 first, as that is
the one that raised to the X.509 group as a potential defect in that
standard.
 
From a process standpoint re X.509 I wanted to let folks know that Hoyt
and I do plan to discuss the whole set of messages that have been
flowing on the X.500, PKIX and ABA lists on this topic and then decide
what, if anything, we should propose be done in X.509. However because
of our overlapping vacation schedule, you won't be hearing that from us
until the end of the month. 
 
Cheers,
Sharon