Henry, Russ and Jim,

I skimmed through the document and read the following two sentences:

   The public key in the request is sent in the clear, and without any
  guarantees that the requestor actually possesses the corresponding
  private key.

   [RFC4211], Appendix C contains a more detailed discussion of why proof-of-
  possession is important.

I have concerns with both sentences.

[RFC4211] is incorrect and this has security implications on the proposed protocol.

A part of Annex C is copied below, with text which should be added in bold characters.

   POP is important because it provides an appropriate level of
   assurance of the correct operation of the PKI as a whole.  At its
   lowest level, POP counters the "self-inflicted denial of service";
   that is, an entity voluntarily gets a certificate that cannot be used
   to sign or encrypt/decrypt information.  However, as the following
   two examples demonstrate, POP also counters less direct, but more
   severe, threats:

      POP for signing keys: it is important to provide POP for keys used
      to sign material, in order to provide non-repudiation of
      transactions.  For example, suppose Alice legitimately has private
      key X and its corresponding public key Y.  Alice has a certificate
      from Charlie, a CA, containing Y.  Alice uses X to sign a
      transaction T.  Without POP, Mal could also get a certificate 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.  One could say, 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.  However, since Alice legitimately has private
      key X and its corresponding public key Y, she will ask her certificate first.
      When the Alice’s certificate will be distributed, Mal takes a copy of
      the public key present in her certificate and requests a certificate
      for himself. By comparing the logs in the CA databases, it is possible
      to know which one asked the certificate first and then tell that Alice
      is the legitimate holder. However, this means that the public key
      must be confidentiality protected during its transit to the RA, in order to
      prevent Mal to copy it. (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.)

      Note that one level of protection can be gained by having Alice
      (as the true signer of the transaction) include in the signed
      information, her certificate or an identifier of her certificate
      (e.g., a hash of her certificate).  Alice could maliciously include
      Mal’s certificate rather than her certificate in the transaction. In case
      of a dispute, the logs present in the CA databases will be used and
      the only legitimate certificate will be the one which was issued earlier.
      It is thus possible to demonstrate that Alice was malicious.
     
The following text from Annex C should be deleted.

      This might make it more
      difficult for Mal to claim authorship; he would have to assert
      that he incorrectly included Alice's certificate, rather than his
      own.  However, it would not stop Alice from falsely repudiating
      her actions.  Since the certificate itself is a public item, Mal
      indeed could have inserted Alice's certificate or identifier 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 certificate is
      issued.

The implication is that the message defined in draft-hotz-kx509 which carries the public key
MUST BE somehow confidentiality and integrity protected.

Denis

PS. I am not on the Kerberos list, so please respond directly or/and to the pkix list.














De :        Stephen Farrell <stephen.farrell <at> cs.tcd.ie>
A :        pkix <pkix <at> ietf.org>, "krb-wg mailing list (ietf-krb-wg <at> lists.anl.gov)" <ietf-krb-wg <at> lists.anl.gov>
Date :        31/05/2012 01:36
Objet :        [pkix] RFC 5742 review of draft-hotz-kx509
Envoyé par :        pkix-bounces <at> ietf.org




Hi,

The independent submissions editor (ISE) has asked the
IESG to do an RFC 5742 review of this [1] document.

That review is to check that the publication of this
independent stream submission would not conflict with
IETF work.

In this case, the work is clearly related to the pkix
and kerberos working groups, hence this mail.

Note: this mail is not a request for a technical review
of the content, but rather asking if publication would
somehow be damaging to the work of these wgs. (If you
do have technical comments, send them to the author
or ISE). If you're not sure about any of that, then
read RFC 5742. [2]

I'll take silence as meaning that nobody thinks that
there's a conflict. If someone thinks there is a
conflict let me, the list, or the wg chairs know. In
due course, I'll be doing my own evaluation as well
of course, as will other IESG members.

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-hotz-kx509-04
[2] http://tools.ietf.org/html/rfc5742

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix