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

From: Carlisle Adams <[email-masked]>
Date: Wed, 8 May 2002 14:15:28 -0400

Hi Santosh,

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	Wednesday, May 08, 2002 2:07 PM
> To: 	'Carlisle Adams'; 'David P. Kemp'
> Cc: 	'500 list (E-mail)'; [email-masked]
> Subject: 	RE: "Authentication" and "Signature" bits...
> 
> 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.
 
I'm not talking about legal mumbo-jumbo.  All I'm saying is that a human may
be able to readily see the difference between random data that has been
signed and meaningful data that has been signed, but in many cases, software
can't.  Certificates and CRLs have a very specific, well-known syntax, so
software *can* distinguish between these and other data.  But deciding
whether the thing that has been signed had the intent of being for
authentication purposes (e.g., a random challenge, or a data origin
authentication e-mail) is a very hard problem.

I disagree that the distinction that has been proposed is meaningful and
useful, completely independent of any legal interpretation.

Carlisle.

---

From: "Tom Gindin" <[email-masked]>
Date: Thu, 9 May 2002 16:42:00 -0400

Carlisle:

      Actually, distinguishing nonces from documents is not a very hard
problem (the lengths are radically different).  The difficulty would be in
distinguishing challenges which are inside larger objects from otherwise
similar objects.

            Tom Gindin

Carlisle Adams <[email-masked]>@mail.imc.org on 05/08/2002
02:15:28 PM

Sent by:    [email-masked]

To:    Carlisle Adams <[email-masked]>, "'David P. Kemp'"
       <[email-masked]>, "'Santosh Chokhani'"
       <[email-masked]>
cc:    "'500 list (E-mail)'" <[email-masked]>,
       [email-masked]
Subject:    RE: "Authentication" and "Signature" bits...

Hi Santosh,

      ----------

      Carlisle:

      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.

I'm not talking about legal mumbo-jumbo.  All I'm saying is that a human
may be able to readily see the difference between random data that has been
signed and meaningful data that has been signed, but in many cases,
software can't.  Certificates and CRLs have a very specific, well-known
syntax, so software *can* distinguish between these and other data.  But
deciding whether the thing that has been signed had the intent of being for
authentication purposes (e.g., a random challenge, or a data origin
authentication e-mail) is a very hard problem.

Carlisle.

---

From: Carlisle Adams <[email-masked]>
Date: Thu, 9 May 2002 17:49:06 -0400

Hi Tom,

> ----------
> From: 	Tom Gindin[SMTP:[email-masked]]
> Sent: 	Thursday, May 09, 2002 4:42 PM
> To: 	Carlisle Adams
> Cc: 	'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)';
> [email-masked]
> problem (the lengths are radically different).  
 
Often, yes; but of course this can't be universally true.  There are
certainly some meaningful messages that are short.  And there is a whole
grey area if the thing that is signed happens to be the hash of a larger
document, since the hash may very well be the same size as a nonce.

> The difficulty would be in
 
Agreed.

The only point I'm making is that there is no hard-and-fast rule that will
allow software to distinguish (every time!) between a meaningful message and
a nonce.  If you can't guarantee this distinction, then two separate A and
DS bits leads to the same quagmire we've had for the DS and NR bits.

It has been suggested (in an off-list message to me) that applications know
their own contexts and therefore can always make this distinction in the
messages they process.  Perhaps that's true, but I'm skeptical.  I'm of the
belief that signing a message with the sole intent of data origin
authentication ("Carlisle originated this message") is as much
'authentication' as signing a nonce.  It's proof-of-possession of a private
key; it's challenge-response without the challenge (or perhaps with an
implied challenge); it's a mechanism for letting the receiver know who is at
the other end of the channel.  This use is not for non-repudiation purposes;
this is simply DOA.  Given that premise (i.e., that DOA is a valid form of
authentication), then I don't see how even applications that know their
contexts can make the distinction.

I don't think that separating A and DS into two bits serves any meaningful
purpose.  It's all DS.

Carlisle.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 10 May 2002 21:40:42 +1200 (NZST)

Tony Bartoletti <[email-masked]> writes:

>But why should a CA ever have access to even a NR=0 private key?  Why should
>they need to attest to that which should be standard practice?

Having the CA generate the user's key and send it to them as a PKCS #12 file is
depressingly common.  With a number of CAs, that's the only way to get a cert
from them (I have a paper on this and other stupidity at Usenix Security '02).

Peter.

---

From: "Tom Gindin" <[email-masked]>
Date: Fri, 10 May 2002 07:53:16 -0400

Carlisle:

      Responses below.  In general IMO, a nonce and an NR message can
certainly be distinguished from each other by software, but not all objects
to be signed fall into these two categories.  Short of declaring that the
only objects to be signed in NR mode must be from a (fairly small)
enumerated set of formats (SignedData, XMLDSIG, and maybe a few more) and
have specific indicators that they are NR (which must be standardized from
each format), I don't see any way to block the use of a signature by a
non-NR certificate for NR in software.  One of the purposes of having the
NR bit (perhaps the strongest) is to warn a relying party that NOTHING
signed by the key in a DS=1,NR=0 certificate is to be considered as
non-repudiable.

            Tom Gindin

Carlisle Adams <[email-masked]> on 05/09/2002 05:49:06 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "'David P. Kemp'" <[email-masked]>, "'Santosh Chokhani'"
       <[email-masked]>, "'500 list (E-mail)'"
       <[email-masked]>, [email-masked]
Subject:    RE: "Authentication" and "Signature" bits...

Hi Tom,

      ----------

            Carlisle:

            Actually, distinguishing nonces from documents is not a very
      hard
      problem (the lengths are radically different).

      [TG] Any meaningful application verification of such a hash would
      have to go back and verify the hash, so the size would be
      distinguishable.

      The difficulty would be in
      distinguishing challenges which are inside larger objects from
      otherwise
      similar objects.

Agreed.

The only point I'm making is that there is no hard-and-fast rule that will
allow software to distinguish (every time!) between a meaningful message
and a nonce.  If you can't guarantee this distinction, then two separate A
and DS bits leads to the same quagmire we've had for the DS and NR bits.

It has been suggested (in an off-list message to me) that applications know
their own contexts and therefore can always make this distinction in the
messages they process.  Perhaps that's true, but I'm skeptical.  I'm of the
belief that signing a message with the sole intent of data origin
authentication ("Carlisle originated this message") is as much
'authentication' as signing a nonce.  It's proof-of-possession of a private
key; it's challenge-response without the challenge (or perhaps with an
implied challenge); it's a mechanism for letting the receiver know who is
at the other end of the channel.  This use is not for non-repudiation
purposes; this is simply DOA.  Given that premise (i.e., that DOA is a
valid form of authentication), then I don't see how even applications that
know their contexts can make the distinction.

[TG] I don't think this holds up well.  If I present a CMS message with an
NR assertion in it (say one of the Signature Policies that purports to be
non-repudiable), you'd better not sign it in challenge-response mode.

Carlisle.

---

From: Hal Lockhart <[email-masked]>
Date: Fri, 10 May 2002 11:03:43 -0400

> Peter Gutmann responded:

Commonly cited reasons include ability to generate higher quality random
numbers and performance issues around time to generate large keys. (You
might think the random number issue would be moot by now, but I have yet to
see a commercial security product of any kind, not just PKI, that uses the
Pentium III hardware RNG.)

Also of particular interest to you Tony, all of the  US government RFPs I
have seen (including DOE) demand a key recovery capability. I don't know if
this is really being used, but it has become a product checkoff item.

Hal

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 10 May 2002 11:03:41 -0700

At 11:03 AM 5/10/02 -0400, Hal Lockhart wrote:

>have seen (including DOE) demand a key recovery capability. I don't know 
>if this is really being used, but it has become a product checkoff item.

Hal,

I was unaware that this applied to signature keys, but it may well be as 
you say.  In that case, it would make sense to have the ability for the CA 
to assert in the certificate that the private key was/was-never in their 
possession (rather than in a policy that may be variably interpreted.)

(I assume the rationale is that a very-strong signature key can be a 
very-strong crypto-key, and not that the government reserves the right to 
impersonate me, but that may be naive.  I suppose all governments reserve 
to themselves the right to make the false appear true, in the name of 
national security ... )

____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Hal Lockhart <[email-masked]>
Date: Fri, 10 May 2002 14:43:56 -0400

> you say.

Well a S/MIME cert would have DS=1 and NR=0, which is the case you specified
in your last message. 

However, I don't believe there is any conspiracy involved, or any deep
thinking of any kind. I think the reasoning goes something like this.

1. Key escrow is a feature that might be useful in some cases.
2. The more features a product has, the better product it is, all other
things being equal.
3. The RFP should ask for key escrow.

Hal

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 10 May 2002 15:52:05 -0700

At 02:43 PM 5/10/02 -0400, Hal Lockhart wrote:
>Well a S/MIME cert would have DS=1 and NR=0, which is the case you 
>specified in your last message.

In my mind, it is antithetical to escrow an authentication key (granted, 
the authentication/encryption distinction may be problematic.)  If a 
process involves a "mix" of crypto and authentication, that application of 
crypto should be one where "permanent loss of data" is tolerable (and thus 
key-escrow unmotivated), as opposed to "bulk storage crypto".

(Just goes to show, a "crypto-key-usage-bit," as in 
crypto-versus-signature, may "mechanically" mean apply/don't-apply a 
crypto-algorithm, and yet it makes more sense (and is harder to 
distinguish) crypto to protect data in transit versus crypto for safe storage.)

On the lighter side ...

>1. Key escrow is a feature that might be useful in some cases.

An automobile-mounted flamethrower may be useful in some cases.

>2. The more features a product has, the better product it is, all other 

A car with a flamethrower is better than one without, all other things 
being equal.

>3. The RFP should ask for key escrow.

I want one for my car, too.  ;)

Cheers,

____tony____