Subject: RE: non-repudiation, was Re: proposed key usage text

From: Peter Williams <[email-masked]>
Date: Mon, 6 Dec 1999 17:44:12 -0800

-----Original Message-----
From: Ed Gerck
To: Peter Williams
Cc: [email-masked]
Sent: 12/3/99 8:31 PM
Subject: Re: non-repudiation, was Re: proposed key usage text

Peter Williams wrote:

> <snip, snip>
>
> Perhaps, what we need is the "durable communications"
> assertion bit.
>
> Binding NR to asymmetric signatures is just a bad idea, in
> my view. Its pretty clear to me that the EC directive will
> accept a SSL server-generated, certificate-supported,
> key exchange blob-set as one or more admissable and effective
> electronic signature(s), just as it would an asymmetric
> signature blob.
>
> You may have got the NR defn off of the NSA-aberism of
> time-dependent, not evidence-dependent semantics, but its
> still linked to asymmetric signatures, and thus
> at odds with the technology-neutral regulatory
> frameworks.

Peter:

I have no doubt that non-repudiation can be based on
symmetric signatures.  This is also mentioned in this
list's archives, and by more than one poster.  I may say
thus this WG is NOT binding NR to asymmetric signatures,
but just specifying the least requirements for NR *when* it
is based on asymmetric signatures.  I think your comment
helps make this clear.

Ed:

Let me be even more clear then, based on what
you seem to assert. Its easier to specify in the positive,
to remove interpretability:-

"Use of the NR bit, as to be defined in the PKIX son
of 2459, does not require that one use a digital signature 
verification key in order to obtain that service."

If this is true, for PKIX, then I recommed we
add a statement along the lines of the above
quoted assertion to the text on NR key usage.

Now, I must also say that nowhere in X.509 it is specified
that NR can NOT be based on symmetric signatures.  It
only so restricts *authentication*, to wit:

"The strong authentication method specified in this
Recommendation | International Standard is based upon
public-key cryptosystems."

Thus, since we did manage to more clearly differentiate
between authentication and non-repudiation functions
in PKIX, which separation X.509 also predicates as quoted
in the archives, it is IMO clear that yours is a valid
question to ask -- "Why stop the NR  discussion at
asymmetric signatures in PKIX? Why not be more
technologically-neutral?"

Well, PKIX itself is NOT technologically-neutral
for authentication (see above) --  which may already
preempt the "technology-neutral" argument for
PKIX in the eyes of many.  So, this may be one
answer to your question -- it is not required.

However, in time and again, I believe facts will show
that unless we enlarge our models (e.g., with symmetric
NR) we will not be able to represent the real-world as
we ourselves enlarge it.  Then, IMO your question will
be rediscovered and a solution will be more clearly
needed.  But, right now, I believe we should try to
achieve closure on the current (limited, but useful)
definition of NR in PKIX.  It will be always fun
though to investigate the next issues.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Mon, 06 Dec 1999 20:20:24 -0800

Peter:

First, excuse me for resetting the messages but your
last post in forward format with mixed text, mine and
yours, but without any ">" reply level indicator might
be even more confusing if replied ;-)

You point out that the proposed NR text in PKIX is not
"technologically-neutral" because it relies on asymmetric
signatures in order to specify the NR services.

I agreed -- however I observed:

1.  this WG is NOT binding NR to asymmetric signatures,
but just specifying  the least requirements for  NR *when*
it is based on asymmetric signatures.

2.  some posters in this WG (myself included) have already
pointed out that NR *can* be based on symmetric signatures
(see archives).

3. nowhere in X.509 it is specified that NR can NOT be based
on symmetric signatures.

4.  X.509 does specify however that authentication can NOT
be based on symmetric signatures, as given in the segment:
"The strong authentication method specified in this
Recommendation | International Standard is based upon
public-key cryptosystems."

5. I do not feel it is necessary *now* to additionally require PKIX
to be "technologically-neutral" for non-repudiation  and additionally
specify a symmetric signature method for NR -- since PKIX  is not
technologically-neutral for authentication, by definition.

However, please note that other authentication techniques besides
public-key digital signatures are clearly positively allowed (as you
argue for) in the provision of NR services, as already written in the
proposed PKIX key usage text.  This occurs when the text specifies
that "[a] signature policy identifier embedded in the signed data MAY
be used to explicitly provide context." -- e.g., I can embed a symmetric
NR signature in the asymmetrically signed data, according to a policy
identifier that I am allowed to embed in the asymmetrically signed data,
which policy identifier provides the context for the NR services ... based
on the embedded symmetric signature.

Thus, by explictly allowing the signed data itself to provide for NR context,
the current key usage text already says what you (correctly, IMO) miss:
PKIX does not require that one uses only the fixed context of  public-key
digital signatures in order to obtain a NR  service.  In a universal
Turing machine analogy, the signed data provides a secure channel both
for "code" (the to-be-interpreted bytes that denote context for a NR
service) as well as for "data" (the uninterpreted bytes that support
the NR service).  You define what is "code" and what is "data" -- but, if
you do not, the default is NR based on the context of asymmetric keys.

Cheers,

Ed Gerck