Re: Comments on the PKIX Roadmap

[Sean Turner <turners@xxxxxxxx>]

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