Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap

From: Sean Turner <[email-masked]>
Date: Mon, 01 Nov 1999 13:52:10 -0500

Ed Gerck wrote:
...snip

> .
> There are other problems with the new roadmap (see my previous msgs) and problems
> which I did not address either --- and which IMO seriously undermine its usefulness
> to reflect what this WG discussed and what the protocols are for.  Two of its key
> purposes -- and that is why I suggested it should be recalled and redone.  It may be
> that the new PKIX roadmap  "captured the WG's feelings from around mid '98
> timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
> around end '99 timeframe?

We'll update the NR discussion in the draft roadmap, but could you enumerate your other
concerns?  I think most of the ones I've seen so far dealt specifically with the NR bit
discussion.

Cheers,

spt

---

From: Ed Gerck <[email-masked]>
Date: Mon, 01 Nov 1999 11:53:42 -0800

> concerns?  I think most of the ones I've seen so far dealt specifically with the NR bit

The NR discussion involved not only the question of multiple NR meanings, but also the
ordering of NR meanings in "strength", the encoding of NR meanings in keyUsage bits
and/or in policy extensions, the independence/dependence of NR upon CAs, and the
perception that "intent" was not the issue in NR at all -- since NR can make a latter
provably false act to be binding (e.g., a false signature that cannot be distinguished from
a true signature when presented).

Besides, the CRL and the timestamp discussions had also IMO some interesting points
which I missed in the new roadmap.  If this would be useful, I could review them in some
time and present a list -- however, their main dialogue parties could do this much better
and faster, I believe.

Cheers,

Ed Gerck

---

From: Sean Turner <[email-masked]>
Date: Wed, 03 Nov 1999 18:03:59 -0500

Denis,

Thanks for the comments.  Mine are in line.

Denis Pinkas wrote:

> Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>
>
> Here are some comments and change text proposals followed by some
> typos (not all !) to prove that I skimmed through the draft. The
> problem was to get the time to read it and comment on it. :-)
>
> I would like to mention upfront that the draft is very valuable in
> general, in particular for the sections related to the historical
> construction and the naming constraints. However, ...  :-)
>
> Page 9:  The text says:
>
>    Of course, if
>    a true non-repudation service is to be provided additional
> services
>    that prove the data was actually in the possesion of the subject
>    requesting the time stamp. So, the [DVCS] draft was developed to
>    provide two mechaisms to prove the subject actually possed the
> data.
>    In addition, [DVCS] provides two additional services: one to
> verify
>    all signatures attached to the signed document using all
> appropriate
>    status information and PKCs and one to verify and assert the
> validity
>    of one or more PKCs at the specified time. Thoughtfully, [DVCS]
>    permits the [TSP] protocol to be used as one of the time stamp
>    tokens.
>
> I would propose instead:
>
> [DVCS] allows to verify and assert the validity of all signatures
> attached to the signed document using all appropriate status
> information and PKCs or to verify and assert the validity of one or
> more PKCs at the specified time.
>

Okay I can add this.  Other have commented in private e-mail to expand
the DVCS description to include:

- delegation of verification to trustworthy servers
- Chaining of verifications
- The DVCS not only validates the signature of the document,  it checks
the validity of a document.

I'll make sure your suggestions get worked in and the others too.

>
> Page 9: The text says:"
>
>    [ETNPT] was developed to use [DCVS] to maintain the trust in a
> token
>    issued by a non-repudiation Trusted Third Party (NR TTP) after
> the
>    key initially used to establish trust in the token expires.
>
> I would propose instead:
>
> [ETNPT]was proposed to maintain the trust in a token  issued by a
> non-repudiation Trusted Third Party (NR TTP) after the key initially
> used to establish trust in the token expires. However, since TSP
> provides that service, its goal needs to be clarified.
>

Okay except for the last sentence.  I thought [ETNPT] gave you a format
to store the information locally (like on your HD).  I wasn't sure if
TSP provided the same function (thought I guess it could if you stored
the message).  If you think the goal for [ETNPT] needs to be clarified
we should do that in a separate e-mail thread about ETNPT and not just
put it in the roadmap.

>
> Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"
>

Somebody else suggested "Time Stamping and Data Validation and
Certification Server Protocols" can we use that instead?

>
> Page 39: Section on POP. It should be noticed that POP is NOT always
> needed. For some (old) "poorly designed" protocols, POP is needed
> when the SAME key is being used for authentication purposes and non
> repudiation purposes. Basically, if the protocol makes sure that the
> identifier of the public key certificate is protected by the end
> user signature, then POP does not need to be performed by the CA.
> For the case of encryption, see the proposed text replacement. Here
> is a full text replacement for that topic:
>

In general, I have no real concerns with what you propose just a few
questions.

>
> 5.2 POP
>
> Proof of Possession, or POP, or also CA POP, means that the CA is
> adequately convinced that the entity requesting a PKC containing a
> public key Y has access to the private key X corresponding to that
> public key.
>
> There has been some debate whether POP was or not needed.
>
> This question needs to be addressed separately considering the
> context of use of the key, in particular whether a key is used for
> an authentication or non repudiation service, or in a
> confidentiality service. Note that this does not map to the key
> usage bit directly, since it is possible to use a confidentiality
> key to perform an authentication service, e.g. by asking to decrypt
> an encrypted challenge.
>
> 5.2.1 POP for Signing Keys
>
> Suppose Alice legitimately has private key X and its corresponding
> public key Y. Alice has a PKC from Charlie, a CA, containing Y.
> Alice uses X to sign a transaction T. Without POP, Mal could also
> get a PKC from Charlie containing the same public key, Y. Now, there
> are two possible threats: Mal could claim to have been the real
> signer of T; or Alice can falsely deny signing T, claiming that it
> was instead Mal. Since no one can reliably prove that Mal did or did
> not ever possess X, neither of these claims can be refuted, and thus
> the service provided by and the confidence in the PKI has been
> defeated. (Of course, if Mal really did possess X, Alice's private
> key, then no POP mechanism in the world will help, but that is a
> different problem.)
>
> Protection can be gained by having Alice, as the true signer of the
> transaction, include in the signed information her PKC or an
> identifier of her PKC (e.g., a hash of her PKC). This makes
> impossible for Mal to claim authorship because he does not know the
> private key from Alice and thus is unable to include his certificate
> under the signature.
>

The last sentence says "impossible."  What it used to say was:

This might make it more difficult for Mal to claim authorship - he would
have to assert that he incorrectly included Alice's PKC, rather than his
own. However, it would not stop Alice from falsely repudiating her
actions. Since the PKC itself is a public item, Mal indeed could have
inserted Alice's PKC into the signed transaction, and thus its presence
does not indicate that Alice was the one who participated in the
now-repudiated transaction. The only reliable way to stop this attack is
to require that Mal prove he possesses X before his PKC is issued.

What was it that you didn't like from the previous text?

>
> The adequate protection may be obtained in the general case, by
> mandating the inclusion of a reference of the certificate every time
> a signature (or non repudiation) key is being used in a protocol.
>
> However, because all the protocols were not doing so, a conservative
> measure has been taken by requesting POP to be performed by CAs. It
> should thus be understood, that this measure is not strictly
> necessary and is only a temporary measure to make old protocols
> secure. New protocols or data formats are being developed. If the
> key being used is always used in a context where the identifier of
> the certificate is included in the protocol, then POP by the CA is
> not necessary. The inclusion of the identifier of the certificate in
> the protocol or data format may be understood as POP being performed
> at the transaction time rather than by the CA, at the registration
> time of the user in the PKI.
>

The text indicating that the need for POP for signing keys not used for
non-repudiation was removed.  What didn't you like about it?

I think the rest of the POP rewrite looks fine.

>
> 5.2.2 POP for Key Management Keys
>
> Suppose that Al is a new instructor in the Computer Science
> Department of a local University. Al has created a draft final exam
> for the Introduction to Networking course he is teaching. He wants
> to send a copy of the draft final to Dorothy, the Department Head,
> for her review prior to giving the exam. This exam will of course be
> encrypted, as several students have access to the computer system.
> However, a quick search of the PKC repository (e.g., search the
> repository for all records with subjectPublicKey=Dorothy's-value)
> turns up the fact that several students have PKCs containing the
> same public key management key as Dorothy. At this point, if no POP
> has been done by the CA, Al has no way of knowing whether all of the
> students have simply created these PKCs without knowing the
> corresponding private key (and thus it is safe to send the encrypted
> exam to Dorothy), or whether the students have somehow acquired
> Dorothy's private key (and thus it is certainly not safe to send the
> exam).
>
> The later case may seem unsafe. However, if the other students have
> acquired the key, they do not even need to publish their
> certificates and can simply decrypt in parallel.
>
> The end story is that, if the key only known to Dorothy, there is no
> problem. Thus POP by the CA is not needed.
>
> If the key, like a Diffie-Hellman key, is used for an authentication
> service the answer depends from the protocol being used. In the
> former example, the decryption was done locally and no data was sent
> back on the wire. In an authentication protocol, the story is
> different because either some encrypted or decrypted data is sent
> back. If the data sent back contains the identifier of the
> certificate in a way that it cannot be modified without that
> modification being detected, then there is no need for POP. On the
> contrary, POP by the CA is needed.
>
> As a conservative measure, POP for encryption keys is recommended,
> but it should be realized that it is not always needed.
>
> In general it should be noticed that POP at the time of the
> transaction is much superior than POP made by the CA, since it is
> possible in real time to be sure that everything is correct, rather
> than rely on that verification to be done at the time of
> registration by the CA. Should the CA fail in that verification,
> then there is a security breach. On the contrary, doing POP at the
> time of the transaction, eliminates that problem.
>
> CMP requires that POP be provided for all keys, either through on-
> line or out-of-band means. There are any number of ways to provide
> POP, and the choice of which to use is a local matter. Additionally,
> a PKC requester can provide POP to either a CA or to an RA, if the
> RA can adequately assure the CA that POP has been performed. Some of
> the acceptable ways to provide POP include [the following text has
> been kept unchanged]:
>
>  - Out-of-band means:
>
>  - For keys generated by the CA or an RA (e.g., on a token such as
>    a smart card or PCMCIA card), possession of the token can
>    provide adequate proof of possession of the private key.
>
>  - For user-generated keys, another approach can be used in
>    environments where "key recovery" requirements force the
>    requester to provide a copy of the private key to the CA or an
>    RA. In this case, the CA will not issue the requested PKC until
>    such time as the requester has provided the private key. This
>    approach is in general not recommended, as it is extremely
>    risky (e.g., the system designers need to figure out a way to
>    protect the private keys from compromise while they are being
>    sent to the CA/RA/other authority, and how to protect them
>    there), but it can be used.
>
>  - On-line means:
>
>  - For signature keys that are generated by an EE, the requester
>    of a PKC can be required to sign some piece of data (typically,
>    the PKC request itself) using the private key. The CA will then
>    use the requested public key to verify the signature. If the
>    signature verification works, the CA can safely conclude that
>    the requester had access to the private key. If the signature
>    verification process fails, the CA can conclude that the
>    requester did not have access to the correct private key, and
>    reject the request.
>
>  - For key management keys that are generated by the requester,
>    the CA can send the user the requested public key, along with
>    the CA's own private key, to encrypt some piece of data, and
>    send it to the requester to be decrypted. For example, the CA
>    can generate some random challenge, and require some action to
>    be taken after decryption (e.g., "decrypt this encrypted random
>    number and send it back to me"). If the requester does not take
>    the requested action, the CA concludes that the requester did
>    not possess the private key, and the PKC is not issued.
>
> Page 42: Section 5.3.1  on the key usage bits. The story about the
> digital signature and NR bit is not correct. Setting the NR bit does
> NOT means that the Signature bit must be present. [FORMAT] is clear
> on that topic. 4 th line from first paragraph. Remove "and/or
> nonRepudiation" then after make "bit" singular (i.e. remove the s).
>

Okay.

>
> Page 43. In the note in the middle of the page, delete the sentence:
> "However, the nonRepudiation key usage bit is provided as an
> indicator that such keys should not be used as a component of a
> system providing a non-repudiation service."
>

Okay.

>
> 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.
>
> 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.
>
> A question came whether it was appropriate to turn on both the
> signature bit and the NR bit. It is possible to use the same key for
> two different purposes, but there is some danger to do so, if it may
> exist cases where the protocol invoking the signature key is not
> fully known. In such a case, it could happen, that instead of asking
> the signature of a challenge, the protocol could ask a signature
> over a hash that represents the hash of some transaction. A signer
> could then agree on the terms of that transaction, instead of
> opening a door which would be the case if the challenge is correctly
> signed. In order to avoid this kind of problem, two different keys
> are recommended. However, if, when using the same key for two
> different purposes, it can be made sure that such misuse of the key
> cannot happen, then this is not a problem. Since in many cases, it
> is difficult to make the verification and thus get that assurance, a
> good practice is to set only one bit at a time and thus use two
> different keys."
>

On this one, I'm going to let the dust settle a bit before I make a
change.  So I'm going to keep your comments in mind when I rewrite the
section.  I'll make sure the discussion gets to the list.

>
> Page 44. Section 5.4. Trust model. IMO, the approach that is
> described is not appropriate. Trust is not related to an entity CA,
> but to the trust placed by the EE in the context of an application.
> Also there is not ONE trust point necessarily, but several. The
> choice is NOT between a TOP CA (which does not necessarily exist)
> and the local CA of the EE. The whole section should be changed to
> reflect this.
>
> Proposed change :
>
> " An important design decision is which trust pointS for a
> particular application should be used by a particular EE. This
> decision depends from the context of use, i.e. from the kind of
> application being used. For example, in a SET transaction, the bank
> sets a single trust point and the end user has no choice about this.
> In a different context the user (or a domain administrator) may
> select which trust points to use.
>
> More text might be needed along these lines.
>

Okay for the next version I'll try to have something more along your
lines.  It was just something I threw together.

> A few typos (not all):

I'll get these in the next go around..

>
> Page 5: Sercurity
> Page 7: refrnce, posess, complimentary.
> Page 8: devloped
> Page 9: mecaisms , possesion, possed, repudation,  "can produced" to
> be replaced by "can be produced"
> Page 13: informtoin
> Page 21: In the sentence "[TSP] also defines" replace "defines" by
> "defined".
> Page 25: "Diffie-Hellman a key" to be replaced by "a Diffie-Hellman
> key"

Cheers,

spt

---

From: "Parag Namjoshi" <[email-masked]>
Date: Thu, 4 Nov 1999 18:05:22 +0530

>>    token issued by a non-repudiation Trusted Third Party (NR TTP) after
>>    the key initially used to establish trust in the token expires.
>>     I would propose instead:
>>

The basic purpose of the draft is to keep alive the trust in "long living"
non-repudiation tokens/certificates even after the key used by the *service*
( say TSA )to sign the token has expired. This is logical extension of the
the services provided by TSA/DVCS for extending the lifetime of signatures ,
to extend lifetime of their own signatures. (somewhat similar to "old with
new" of CMP.)

The draft uses the CS (now "VSD") service from DVCS
to "recertify" the original token/certificate. The  ASN structure
(local storage format ) is defined so that opeartion of the
recertification of token & later verification ( maybe after 10 years
when service has changed keys , say 5 times ) can be performed easily.
(This would be much simpler and faster than retrieving tokens from
an archive , getting some kind of certification from the service
provider about its authenticiaty ect which would involve human
interaction thus (comparatively) much larger delays.)

The format also allows for linking multiple such tokens (very likely from
different service provider ) for same data. (Each of these tokens
can (and should) be recertified to keep alive the initial trust in the
token.)

This is absolutely necessary in the case that your service
does not provide for archiving . And even if the archiving
is provided you may not want to put all eggs in one basket.
As an example,you do trust the service to protect its signing key well
but not with the lagre token archive over a long period of time.

I hope I have clarified the goals for the draft well enough.

Note : The draft is somewhat out of date since after it was written ,
2/3 versions of TSA & DVCS draft have come out.

Regards,
Parag.

> to store the information locally (like on your HD).

>I wasn't sure if

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Nov 1999 15:20:55 +0100

Sean,

Before packing to Washington, a short answer. I have deleted some
stuff to make this answer more readable.

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

(...)

> the validity of a document.

For the last sentence, I do not think so. The content of the signed
part is not "validated"

(...)

> we should do that in a separate e-mail thread about ETNPT and not just

I will do so.

> Certification Server Protocols" can we use that instead?

The current title of TSP does not contains "and Data Validation and
Certification Server Protocols". Having TSP addressed separately
seems more appropriate.

> In general, I have no real concerns with what you propose just a few

(...)

> What was it that you didn't like from the previous text?

"Impossible " means impossible, not "more difficult". :-)

> non-repudiation was removed.  What didn't you like about it?

The above is valid for all keys, as soon as the identifier of the
certificate may be closely tied to the signature key.

> I think the rest of the POP rewrite looks fine.

(...)

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Nov 1999 15:45:21 +0100

Parag,

This E-mail was initiated by a comment on the roadmap, but since
Sean erecommned to discuss this separately I changed the title of
this thread to ETNPT only.

> to extend lifetime of their own signatures. (somewhat similar to "old with

I still have difficulties to understand the rational for the (rather
complex) scheme that is presented. The basic time stamping protocol
provides a token (TST) that allows to make sure before which time a
document and/or a certificate was signed. If some signed data needs
to be protected by a time stamp, it seems more natural to append the
TST to the data structure rather than going down a tree of
"NRStorage". 

In addition, the data structure that is presented is twice
recursive. :-(

Thus I am wondering the need for such a document. If you are present
in Washington, I would appreciate a talk on that topic.

Regards,

Denis

---

From: "Parag Namjoshi" <[email-masked]>
Date: Fri, 5 Nov 1999 18:50:08 +0530

Hi Dennis,

I am changing the title (again) to ETNRT. Never figured out what ETNPT was
:-).

> In addition, the data structure that is presented is twice

The scheme in its entirity is indeed complex. The structure reflects the
complexities introduced due to the long period of time over over which the
tokens may remain valid. During this periods the "maintainance" of the token
may have to be taken over by different entity. Multiple copies of the token
may exist & may have to be reconciled. The format allows to create "chain of
custody" for the token as it's updated by different entities (eg.
responsibility
of maintanance of token may change or two tokens for same data may be
combined
and maintained as one after living separartely for some time). The format
will
provide *additional evidence* about the token,its managers and their
diligence.

But everyone need not use it to complete extent.
Implementations will have varying levels of complexity .
The simplest ones will just use the scheme to validate tokens with
comparatively smaller lifetimes to tide over imminent key update.
(In fact this will be the most common usage of the format)
In this case format will degenerate to simple pair of tokens. Even
timeToNextUpdate need not be present.

Smarter implementations will have chaining (ie appending
as you suggest) to provide basic functionality.A full featured
implementation
will support management of complete trees and may well go beyond that by
using policies to reconcile trees from different servers.

> in Washington,

No I won't be there :(

Regards,
Parag.

>I would appreciate a talk on that topic.