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

From: Peter Williams <[email-masked]>
Date: Thu, 09 May 2002 14:43:25 -0700

Let me ask the dumb questions, and
then comment, publicly.

A1: 

An OCSP responder inevitably signs
an OCSP responses, which contains a
nonce and highly-legalistic reliance data. The
data is sent, sometimes by a TTP grade
operator, to influence reliance
on certificates. There is
no intention that the OCSP response
is necessarily a set of NR assertions,
however.

I think in your scheme, we
use:

"nonceSign", "digitalSignature|dataSign"

Is this correct?

A2:

A DPV responder will act
similarly to an OCSP responder,
with the added twist that its operator
necessarily makes NR assertions 
(by requirements of this WG), in 
addition to signing a nonce,
and various pieces of reliance
data to be used by a relying
party application in deciding
how to use a certificate path.

I think in your scheme, we
use:

"nonceSign", "digitalSignature|dataSign"

Is this correct?

Conclusion 1: in the new scheme, there
is now no way - using certificates - for an OCSP 
provider to signal that it intends to upgrade its 
OCSP-based validation service to make NR-grade 
assertions. If an OCSP entity
is to upgrade its assurance level to
offer NR, then it would have to signal
this in an OCSP response extension. That is,
we tag the grade of OCSP signing assurance
via an attribute of the signature (essentially)
in the response, not the certificate.

Conclusion 2: in the case of DPV, with
the new scheme, there is no need
to tag the DPV response with any
NR extension/field signal, as ALL DPV responses 
are NR assertions, by protocol definition. That
is, one cannot run a DPV server
except as a NR service provider. Obviously
the precise meaning of a given signer's NR
semantics will be a function 
of the posted "signing policy" of the 
subscriber.

If this is all correct, I'm happy with all this. It 
removes from the CA the technical perogative of controlling
what subscribers can do with NR assertions -
placing control in the hands
of the protocol designers (just like 
X.400/EDIFACT did) and the  protocol 
operators who perform the act
of signing. This scheme aligns
with the model of PMI's
NR assertions.

In terms of PKIX architecture, relying parties
determine when a security service is a subclass
of NR assertions - based on the protocol
definition, and by inspecting the subscribers
signing policy. This contrasts with
the current scheme - built into PKIX-1 and replacements, 
in which one looks to the CA CP.

Peter.

>>>>-----Original Message-----
>>>>From: Tom Gindin [mailto:[email-masked]]
>>>>Sent: Thursday, May 09, 2002 1:42 PM
>>>>To: Carlisle Adams
>>>>Cc: 'David P. Kemp'; 'Santosh Chokhani'; '500 list (E-mail)';
>>>>[email-masked]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>
>>>>
>>>>      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,
>>>>
>>>>
>>>>      ----------
>>>>      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: "Santosh Chokhani" <[email-masked]>
Date: Fri, 10 May 2002 08:42:29 -0400

Peter:

There are several misunderstandings (in my mind) on your part of what I
suggest.  First of all, I do not say that there is NR or there is no NR.
That is why when people on this list talk about intent and software and
hardware between the human actions, I get lost.

My proposal is very simple, just the way a key can be used for
encryption and signature verification or you can have two different keys
for encryption and signature verification, I want to differential
between signing challenges for entity authentication and signing data
that the user/application has formed/blessed.

In these scenarios for OCSP and DPV, the digital signature (and not the
authentication) bit will be required to be set.  If both are set, it is
ok.  I realize that the protocol, includes echoing the challenge, but
the responder is formulating a transaction as opposed to signing a
challenge in order to provide authentication.

Those who want to solve NR problem, are welcome to.  My precise point is
that NR is not a problem to be solved by PKC.  As it so happens, a key
that is used for digital signature and not for signing challenges may
have a better luck on NR, just like a key that is not used for dual
purpose of signature and encryption (since encryption key may have key
escrow feature to it). 

-----Original Message-----
From: Peter Williams [mailto:[email-masked]] 
Sent: Thursday, May 09, 2002 5:43 PM
To: 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: "Authentication" and "Signature" bits...

A1: 

Is this correct?

A2:

A DPV responder will act

Is this correct?

If this is all correct, I'm happy with all this. It 
removes from the CA the technical perogative of controlling what
subscribers can do with NR assertions - placing control in the hands of
the protocol designers (just like 
X.400/EDIFACT did) and the  protocol 
operators who perform the act
of signing. This scheme aligns
with the model of PMI's
NR assertions.

Peter.