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

[Ed Gerck <egerck@xxxxxxx>]

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