The text states: "The reasoning behind doing POP can be found in
Appendix C in [CRMF]."
Appendix C from [CRMF] states:
POP for key management keys: Similarly, POP for key management
keys (that is, keys used for either key agreement or key exchange)
can help to prevent undermining confidence in the PKI. 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 certificate repository
(e.g., search the repository for all records with
subjectPublicKey=Dorothy's-value) turns up the fact thatseveral
students have certificates 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 certificates 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). Thus, the service to be provided by the PKI
allowing users to communicate with one another, with confidence in
who they are communicating with, has been totally defeated. If
the CA is providing POP, then either no students will have such
certificates, or Al can know with certainty that the students do
indeed know Dorothy's private key, and act accordingly.
I do not believe that refering to this text is adequate nor sufficient.
A real explanation, in the context of DH key exchange, is necessary,
Denis
Some on this list might be interested about this draft. Please send
any comments to ietf(_at_)ietf(_dot_)org.
spt
-------- Original Message --------
Subject: Last Call: <draft-schaad-pkix-rfc2875-bis-03.txt>
(Diffie-Hellman Proof-of-Possession Algorithms) to Proposed Standard
Date: Wed, 05 Dec 2012 14:08:01 -0800
From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
Reply-To: ietf(_at_)ietf(_dot_)org
To: IETF-Announce <ietf-announce(_at_)ietf(_dot_)org>
The IESG has received a request from an individual submitter to consider
the following document:
- 'Diffie-Hellman Proof-of-Possession Algorithms'
<draft-schaad-pkix-rfc2875-bis-03.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-01-02. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair and one method for producing an
integrity check value from an Elliptic Curve key pair. This behavior
is needed for such operations as creating the signature of a PKCS #10
certification request. These algorithms are designed to provide a
proof-of-possession rather than general purpose signing.
This document obsoletes RFC 2875.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix