Subject: Re: New Internet Draft on Non-Repudiation Requirements

From: Denis Pinkas <[email-masked]>
Date: Wed, 01 Sep 1999 10:22:04 +0200

Tom,

You said:
 
>      I think that we should remember that the NR bit is supposed to cause CRL
> archiving  as well.

I am not sure what you mean by this statement. If you mean archiving
by the CA that issued the CRL, then I disagree. If you mean
archiving of CRL by the verifier when it first verifies the
signature, then I agree (but this archiving is not triggered by the
presence of the NR bit). But maybe you mean something else.

Denis

---

From: "Nick Pope" <[email-masked]>
Date: Wed, 1 Sep 1999 12:25:48 +0100

Denis,

It is worth noting that in X.509 clause 11.2, note 2 states:

" If a non-repudiation of data service is dependent on keys provided by the
CA, the service should ensure that all relevant keys of the CA (revoked or
expired) and the timestamped revocation lists are archived and certified by
a current authority."

This has relevance to our current work together as well as this list.  I
believe that the word "timestamp"  refers to just a date a time value, not a
trusted timestamp produced by a timestamping authory.

Nick

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: 01 September 1999 09:22
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: New Internet Draft on Non-Repudiation Requirements
>
>
> Tom,
>
> You said:
>

---

From: Paul Koning <[email-masked]>
Date: Wed, 1 Sep 1999 09:19:22 -0400

>>>>> "Nick" == Nick Pope <[email-masked]> writes:

 Nick> Denis, It is worth noting that in X.509 clause 11.2, note 2
 Nick> states:

 Nick> " If a non-repudiation of data service is dependent on keys
 Nick> provided by the CA, the service should ensure that all relevant
 Nick> keys of the CA (revoked or expired) and the timestamped
 Nick> revocation lists are archived and certified by a current
 Nick> authority."

 Nick> This has relevance to our current work together as well as this
 Nick> list.  I believe that the word "timestamp" refers to just a
 Nick> date a time value, not a trusted timestamp produced by a
 Nick> timestamping authory.

I would think it does need to be a trusted timestamp, because you need 
to be able to verify that information bearing on the validity of
signatures (such as CRLs) indeed did exist at the claimed time.

For example, suppose the CA key was compromised at some time and
revoked.  CRLs known to have been issued before then would be good,
but CRLs not provably issued by then are suspect even if internal data 
in them claims they were old.

	paul

---

From: "todd@gmtsw" <[email-masked]>
Date: Wed, 1 Sep 1999 08:37:28 -0700

Nick, Denis... with regard to the X.509 language... not the issue of the NR
bit -

----- Original Message -----
From: Nick Pope <[email-masked]>
To: Denis Pinkas <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 01, 1999 4:25 AM
Subject: RE: New Internet Draft on Non-Repudiation Requirements

> expired) and the timestamped revocation lists are archived and certified
by

This should maybe read "Timebase Certified revocation lists" rather than
timestamped, unless the operations of CRL will embrace TS and DCS
technologies. The problem is that there is too much generic use of the term
'timestamp'. Since the format of the actual Timestamp is not defined in the
X.509 standard as well, it is confusing and makes the X.509 system dependant
on some undefined, external entity, called in this case "a timestamp"...
Unless the X.509 Timestamp is also to be defined too... maybe not such a bad
idea... (Hoyt/Sharon would X.509 look at embracing timestamping Tokens as
part of the token structure standards?)

It was a good thought to include this language, but in cert processing, the
key issue (pardon the pun)  is that the time data that is included in one
reference point, being *directly* comparable to that coming from other
entities. Otherwise the interoperability gets flushed. Here again we are
back to what the timestamping token or process is used for. To insure that
one is not trying to compare apples to oranges at the transaction level.
That the proofs issued by multiple systems are all comparable against each
other.

> trusted timestamp produced by a timestamping authory.

The context of the term timestamp, in this instance, maybe also refers to a
"legally binding" time value. This is the first place for a parametric data
source, that the term "legally binding" is justified in its use, since if
the trust-anchors for the X.509 process, that is the key info, the timebase
data, the source of the time, etc etc etc, are to be used to support
Commerce, then they too must be referencable. (any comments?)

Todd

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 1 Sep 1999 10:57:30 -0700

What is a "non-repudiation of data" service?

I have never heard that phrase before, in
10 years of doing PKI and/or secure layer
services.

(a) Is it the same as the X.400 proof of origin
with NR, service?

(b) is it the same as the DCS signature, on data
to be certified?

(a) and (b) and quite different, one notes. One
applies to messages in a communication
context, the other to data with no semantics
or context.

In the first case, one is asserting a undeniable
claim of origination, the other of existence. Clearly,
in other service variants, there are other
claims including X.435 "responsibility", and X.400's
claims of receipt, and/or delivery. There
are other telematic-service
related claims, backed up by NR assurances,
including legitimacy and authority, though
these are not modeled by OSI security model or
the ISO NR framework, to my knowledge.

> From: Nick Pope [mailto:[email-masked]]
> Sent: Wednesday, September 01, 1999 4:26 AM
> To: Denis Pinkas; [email-masked]
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Sep 1999 18:14:57 -0400

Todd,

While I appreciate your persistant devotion to a model in which some form
of high assurance, distributed time stamps play a central role, I don't
agree with your interpretation of X.509 requirements re timestamps and
CRLs.  Your interpretation is not consistent with the overall context in
which the X.509 and PKIX standards have been formulated.

Steve