Subject: Re: [pkix] Fwd: Last Call: <draft-schaad-pkix-rfc2875-bis-03.txt> (Diffie-Hellman Proof-of-Possession Algorithms) to Proposed Standard

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Dec 2012 16:31:23 +0100

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 [email-masked].
>
> 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 <[email-masked]>
> Reply-To: [email-masked]
> To: IETF-Announce <[email-masked]>
>
>
> 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
> [email-masked] mailing lists by 2013-01-02. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix