lifetime versus NR, Re: Comments on the PKIX Roadmap

[Ed Gerck <egerck@xxxxxxx>]

Denis Pinkas wrote:

> Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>

Dennis:

The PKIX roadmap is a very creative document. In fact, there is
little resemblance between its contents and the past
messages/consensus in this WG.

> Page 43. About the discussion, starting with "According to
> [SIMONETTI], ..." I would propose a global replacement until the end
> of that topic:
>
> " The intent is that the digitalSignature bit should be set when
> what is desired is the ability to sign ephemeral transactions; e.g.,
> for a single session authentication. These transactions are
> "ephemeral" in the sense that they are important only while they are
> in existence; after the session is terminated, there is no long-term
> record of the digital signature and its properties kept.

The ability to sign ephemeral transactions e.g., single session
authentication has to do with the *authenticated connection*
not with a *signed object* (the certificate) -- so, it is rather easy
to distinguish the DS bit in either case.  There is no need to
yet again redefine non-repudiation as a "non-ephemeral digital
signature" in order to do so:

>When something is intended to be kept for some period of time for
>non repudiation purposes, the nonRepudiation bit shall be set. This
>implies that an application will digitally sign something that may
>be used for non repudiation purposes; this bit must be turn on.

The new confusion introduced by your text (and the roadmap)  is
that non-repudiation has now nothing to do with "preventing the
denial of a previous act" (HAC, Menezes) or even with "protecting
against falsely denying an act" (RFC 2459) but with the *lifetime*
of a digital signature.  Hmmmm... this was never mentioned
in this WG and is clearly a redundant definition -- so, why
have it? To avoid the issue?

Or, perhaps there are those that now say the WG consensus on
NR was "wrong"?  Perhaps, but this should be decided in this list,
not in the roadmap text and not in a redundant definition of
lifetime.

I also note for the record that accepting this would mean to negate the
IETF decision process, which I think is even worse than confusing
"non-repudiation" with lifetime.  Thus, in the best spirit of the Internet
of routing around the damage, I ask for a recall of the roadmap as it is
and for a reinstatement of what was discussed and decided here.
Otherwise, in the future, someone will say "but, there is precedent for
this behavior" and we will have no more roads but just slippery
slopes to map, I am afraid.

Cheers,

Ed Gerck