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

From: Peter Williams <[email-masked]>
Date: Fri, 10 May 2002 13:44:29 -0700

Thanks for responding. Im working hard to really
understand the implications of your model, by
testing it out on protocol examples. I conclude by
suggesting we adopt the model, but work
still to find a home for the signals we
are formalising.

---------------

Correct my errors further, please, in the improved examples, if 
any: Ive seperated out the NR issues from KeyUsage, per your last message, 
and assigned actual internet/intranet protocols a set of appropriate
KeyUsages (per Santosh model).

1. OCSP

Basic OCSP responses: Use "digitalSignature/dataSign" KeyUsage

An OCSP Provider's optional upgrade of an OCSP response to provide some
NR assertions requires the provider's cert to bear an OCSP-NR oid in 
ExtendedKeyUsage  OR protocol specific means are used to signal the
additional NR semantics.

2. DPV

DPV responses: use "digitalSignature/dataSign" KeyUsage

A DPV Provider's formation of NR assertions is implicit, and does not
require that the provider's cert bears a DPV-NR oid in ExtendedKeyUsage.

3. OSI ROS-Bind variants

DAP/DSP/CMIP/ACSE-bind : use "authenthentication/nonceSign" KeyUsage

4. DAP/Directory operations

DAP operation request/responses: use "digitalSignature/dataSign" 
KeyUsage. A Directory Provider's optional upgrade of a signed DAP response
to 
provide some NR assertions means that the provider's cert bears an DAP-NR 
oid in ExtendedKeyUsage OR protocol specific means are used to signal 
NR grade of response.

5. https transport

if any of the X, above, are transferred over https: then
https responder entity has a distinct SSL cert from the X entity, 
where the SSL cert has "authenthentication/nonceSign"  and 
"keyAgreement or keyTransport" KeyUsages. 

The X entity using the https A-entity
has a seperate cert from the https entity. the X cert has
X keyUsages and extendedKeyUsages.

6. SSL+X protocol (e.g. dpv-s, cmp over SSL)

If any of the X application protocols, above, are bound in an application 
context to an SSL entity, then the X-responder has 1 (combined) X-protocol 
and SSL cert with  "authenthentication/nonceSign" and "keyAgreement or
keyTransport" 
KeyUsages (for the SSL requirements) unioned with "X" keyUsages and 
extendedKeyUsages (for the X requirements)

Conclusion:

I think the above realize the model and the intent of
your scheme, in practice. I improved my understanding
by (a) understanding that mere presence of replay nonces,
does not mandate "authentication" KeyUsage, and (b)
NR assertion signals are provided by means other than
KeyUsage bits.

I like your scheme. We now need to suggest
how it can be factored into X.509 without
upsetting legacy applications, whilst clearly
making a complete break with the confused past.

New bits in the KeyUsage bitfield or a new X.509 extension
seem appropriate, as Sharon suggests, rather than
simply redefining legacy bits. But your model for
clearing the confused notions about usages seems 
sound and workable, once we find a home for
the various signals.

>>>>-----Original Message-----
>>>>From: Santosh Chokhani [mailto:[email-masked]]
>>>>Sent: Friday, May 10, 2002 5:42 AM
>>>>To: 'Peter Williams'
>>>>Cc: [email-masked]
>>>>Subject: RE: "Authentication" and "Signature" bits...
>>>>
>>>>
>>>>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...
>>>>
>>>>
>>>>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 19:12:25 -0400

Peter:

What I support is very simple.  We have two bits and have not found a
meaningful way to distinguish between the two.

One bit can be used to sign a challenge generated by some one who wants
to authenticate you and another bit is used to sign data generated by
you or on your behalf that you want to prove to be source of.

One is free to use a single key to sign both (by setting both bits).

That is all I am saying, nothing more, nothing less.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]] 
Sent: Friday, May 10, 2002 4:44 PM
To: 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: "Authentication" and "Signature" bits...

---------------

Correct my errors further, please, in the improved examples, if 
any: Ive seperated out the NR issues from KeyUsage, per your last
message, 
and assigned actual internet/intranet protocols a set of appropriate
KeyUsages (per Santosh model).

1. OCSP

2. DPV

3. OSI ROS-Bind variants

DAP operation request/responses: use "digitalSignature/dataSign" 
KeyUsage. A Directory Provider's optional upgrade of a signed DAP
response to 
provide some NR assertions means that the provider's cert bears an
DAP-NR 
oid in ExtendedKeyUsage OR protocol specific means are used to signal 
NR grade of response.

5. https transport

If any of the X application protocols, above, are bound in an
application 
context to an SSL entity, then the X-responder has 1 (combined)
X-protocol 
and SSL cert with  "authenthentication/nonceSign" and "keyAgreement or
keyTransport" 
KeyUsages (for the SSL requirements) unioned with "X" keyUsages and 
extendedKeyUsages (for the X requirements)

Conclusion:

>>>>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
>>>>>>>>      Actually, distinguishing nonces from documents is not a 
>>>>>>>>very hard problem (the lengths are radically different).  The
>>>>>>>>difficulty would be in
>>>>>>>>05/08/2002 02:15:28 PM
>>>>>>>>      But, on technical grounds, there is a difference between 
>>>>>>>>signing a
>>>>>>>>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
>>>>>>>>meaningful and useful, completely independent of any legal 
>>>>>>>>interpretation.
>>>>>>>>
>>>>>>>>
>>>>>>>>Carlisle.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 11 May 2002 08:54:25 -0400

Peter:

I agree with your examples in items 1, 2, 3, 4, 5, and 6 in terms of key
usage.

In terms of how to achieve NR, I have no proposal in mind.  Your EKU
proposal may work.  NR is one of those things where the actioner can
always claim temporary or permanent insanity and get away with it (just
kidding).

Also, I would like to think that the usage of the two bits is further
explanation as opposed to two new bits, as some one else (I think Dave
Kemp) has suggested.

I also want the list to know the following things:

1.  I have faith in collective intelligence of this group and any
solution they come up with is acceptable to me.

2.  What is not acceptable is this further explanation on the bits being
called a change in semantics.  It smacks of "Cry Wolf" mentality.

3.  It is ok for folks not to accept this if they can show why it breaks
backward compatibility, but this is as good (probably best) a technical
(vice legal) distinction between the two bits as any.  And, no I did not
come up with it.  Some one else on this list did.  I just find it more
acceptable than other distinctions and consistent with the definition of
the extension and how other bits are used in the extension.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Williams
Sent: Friday, May 10, 2002 4:44 PM
To: 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: "Authentication" and "Signature" bits...

---------------

1. OCSP

2. DPV

3. OSI ROS-Bind variants

5. https transport

Conclusion:

>>>>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.
>>>>In these scenarios for OCSP and DPV, the digital signature (and not 
>>>>the
>>>>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
>>>>subscribers can do with NR assertions - placing control in the hands

>>>>of the protocol designers (just like
>>>>>>>>software can't.  Certificates and CRLs have a very specific, 
>>>>>>>>well-known syntax, so software *can* distinguish between these 
>>>>>>>>and other data.  But