[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on the PKIX Roadmap
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.
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.
Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"
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:
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 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.
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).
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."
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."
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.
A few typos (not all):
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"