Subject: Re: NR bit absence, was Re: Deprecate the NR bit?

From: "David P. Kemp" <[email-masked]>
Date: Tue, 7 Sep 1999 08:53:37 -0400 (EDT)

> From: Tony Bartoletti <[email-masked]>
> 
> By "signs a message as NR", I am sure Ed simply means "signs a message
> with the key in question", which can subsequently be shown to have been
> certified with "NR=1".  Thus the relying party, or who-knows-who, may
> attempt to assert NR even though the application may not have cared.
> 
> Is this point in dispute?

No.  I'm not sure what you intend by "the application may not have cared",
but what I mean by it is that the application generated a signed object,
period.

> According to your earlier post, a PKIX-conforming application could apply
> "signature" if the signature bit is set, and ignore any possible NR-bit
> setting.  This is at least a clear position.  You also write that a PKIX-
> conforming CA would not issue certain combinations of key usage bits.

I hope I didn't write that!  I did write that I agreed with the current
PKIX wording that explicitly does not restrict the combinations of key
usage bits, and that such restrictions, if any, should be placed in
community-specific certificate profiles.

I agree with you that "support for legal NR" is related to the binding
between 1) private key and a single individual, and 2) public key/subject
name to a single individual.  I also believe that "support for legal NR"
is also related to the generation of verifiable evidence, and that PKIX
should declare that applications which produce signed objects generate
verifiable evidence, and that applications which sign protocol-internal
data for the purpose of establishing symmetric keys or other ephemeral
data do not generate verifiable evidence.

Thus, I would put a table such as the following into Tom's draft:

Application      DS NR      Result
-----------      -----   -----------------------------------------
signed object:    0  0    prohibited (except for certs/CRLs)
                  0  1    provides "support for legal NR" *
                  1  0    provides Ed's "Proof of Authentication"
                  1  1    provides "support for legal NR" *
authenticated
connection:       0  x    prohibited  (NR bit is "don't care")
                  1  x    provides Authentication (without proof)

* The case where both the private key is bound to the subject and the
  application generates a signed object is the PKIX-defined "technical
  prerequisite" for supporting NR.  Additional (currently not defined)
  conditions, such as evidence of user intent and CA's intent, will be
  required, but are not addressed by the NR keyUsage bit.

---

From: Ed Gerck <[email-masked]>
Date: Tue, 07 Sep 1999 10:12:15 -0700

"David P. Kemp" wrote:

> name to a single individual.

Dave:

Perhaps too much emphasis has been placed here on "single individual",
in both terms.  If we accept that non-repudiation (in whatever form) is
exactly useful when an individual "who" denies signing, then "who" is not
as important as "what", "when" and "how".

Besides, since X.509/PKIX never intended to cover the level of detail
needed to verify "who" (such verification depends on each CA's CPS),
I believe the "who" approach will also lack protocol support unless
it is entirely referenced to the CPS (and, entirely solved there).

>  I also believe that "support for legal NR"
> verifiable evidence,

Agree, but "may generate verifiable evidence".

> and that applications which sign protocol-internal

I think this declaration is far too strong, since the signed evidence may
be asymmetric and thus provide evidence of an act by the other party.

> Thus, I would put a table such as the following into Tom's draft:

Dave: your tables are the best ;-) I would make the following change,
which would accommodate the four types of NR we talked about here --
including the need to have purely syntactical signatures (for example,
to prevent tampering en route):

Application      DS NR      Result
-----------      -----   -----------------------------------------
signed object:    0  0    SYN -- unknown presumption when signing [1]
                  1  0    DS  -- no presumption when signing [2]
                  0  1    POA -- rebuttable presumption when signing [3]
                  1  1    NR  -- irrebuttable presumption when signing [4]
authenticated
connection:       0  x    no presumption of authentication
                  1  x    rebuttable presumption of authentication

where:

[1] SYN (syntactic): signature presumption is unknown (for example,
    unreliable and inaccurate attributions), but the signature
    verifies syntactically. Application: signer is defined by an
    email alias, signs automatically.  Provides message integrity.

[2] DS (digital signature): signature presumptions are denied. The
    signer provides reliable evidence of attribution to itself but
    denies any signing context, even that it knows what was being
    signed. Application: signer wants to send email msgs that are
    both tamperproof and with origin authentication but which do
    not imply any presumed commitment nor liability in case of key
    compromise. Provides authentication.

[3] POA (proof of authentication): signature presumptions are affirmed
    by signer but can be rebutted by signer if insufficient proof of
    authentication is provided by the relying-party.  Application:
    e-commerce when signer needs to affirm a buying order but does
    not want to incur in the liability issues of virus, hackers,
    etc.  NOTE: The issue here is not whether the signer could deny
    the transaction (which is a legal issue), but whether the
    relying-party can provide evidence of authentication that could
    be accepted (or not) as proof; thus a signer may not be able to
    hide behind the POA mode in order to successfully deny a
    transaction in a mood change, if the relying-party can provide
    POA that is deemed (legally or policy-wise) credible enough in
    the operational circumstances.

[4] NR (non-repudiation): signature presumptions cannot be denied
    by signer and are irrebuttable if the signature is authenticated.
    Technical application: signer has a NR certificate which
    can be used within a time window from a caller-ID phone call
    from one specific phone, and which the signer uses to
    immediately command an act (e.g., reboot server) without any
    need (in a threat model) for a confirmation.  Commercial
    application: signer wants bank to move funds without need for
    confirmation, up to amount X.  NOTE: with NR, a false act
    cannot be denied once authenticated -- the metric is not whether
    the act was truthful or not but whether the relying-party could
    not distinguish the *previously* agreed authentication procedure
    (e.g., caller ID plus NR cert within a time window; NR cert
    up to amount X) from a procedure that the signer did *not*
    produce. Note also that this metric does not depend on any legal
    theory that needs to be applied -- as exemplified by the server
    reboot NR example.

Further, with this table there is no indeterminacy when the NR
bit is absent.  As pointed out above, the basis for all four
NR types (yes, absence of NR is a NR type) is technical but
legal context can also be provided if so desired by a CPS,
since the cases correspond to mutually-exclusive legal models
(which also have the same names: unknown presumption, no presumption,
rebuttable presumption, irrebutable presumption).

Cheers,

Ed Gerck

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 07 Sep 1999 11:41:13 -0700

>but what I mean by it is that the application generated a signed object,

Yes, this is exactly my meaning as well.  An application does not "sign as NR"
per se, but the key used in the operation may certainly (later) be shown to
have been "NR certified".  To what effect...?

>community-specific certificate profiles.

Sorry if it looks like I attributed those exact words to you.  But the
terms "PKIX wording that explicitly does not restrict the combinations"
and my "PKIX-conforming application could apply" are in rough agreement.

You gave 3 instances of application key-usage, and indicated that each
usage need only be concerned (PKIX conformance-wise) that its particular
bit is set, and may ignore all others.  But your 3 examples specifically
left out the "interesting one" being debated, and Ed added it to extend
your argument.  This was the DS=1, ignore NR-bit example.

In essence, Ed argues that the "independence" of the individual key-usage
bits does not imply that all key-usages need only examine one bit, nor
that seeking only a proper collection of "bits=1" is sufficient.
 
Perhaps, beyond "PKIX conformance" (and beyond this WG) there need to be
a "Good Housekeeping Seal of Approval" for applications that adhere to
particular behaviors regarding key-usage bit-combos.  But then the PKIX
profile needs to be really neutral on these issues, and not step into it
halfway.

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL