Subject: thisMessage POP (again) - spec is contradictory

From: "Christopher Williams" <[email-masked]>
Date: Tue, 18 Apr 2000 16:36:16 +0100

Sorry to bring this up again, but the spec is still muddled on this issue.

RFC2510bis, section 3.28 says:

"...proof of possession of the private decryption key may be demonstrated
   in one of three ways.

      1) By the inclusion of the private key (encrypted) in the
         CertRequest (in the PKIArchiveOptions control structure)."

This suggests that POP is implicit, because the EE is asking the CA to
archive the private key and providing the private key in an ArchiveOptions
control.  The CA can decrypt the private key in the ArchiveOptions control
and match it against the public key in the CertTemplate.

Appendix D then says:

"POPOPrivKey ::= CHOICE {
    thisMessage       [0] BIT STRING,
-- **********
-- * the type of "thisMessage" was mistakenly given as BIT STRING in
-- * RFC 2511; it should have been "EncryptedValue" (in accordance with
-- * Section 3.2.2 of this specification).  Therefore, this document makes
-- * the behavioral clarification of specifying that the contents of
-- * "thisMessage" MUST be encoded as an EncryptedValue and then wrapped
-- * in a BIT STRING.  This allows the necessary conveyance and protection
-- * of the private key while maintaining bits-on-the-wire compatibility
-- * with RFC 2511.
-- **********
    subsequentMessage [1] SubsequentMessage,
    dhMAC             [2] BIT STRING }"

These instructions are not compatible:

1. They tell you to do two different things - stick the private key in an
ArchiveOptions control OR in an EncryptedValue.
2. If the certificate request contains an ArchiveOptions control, the
contents of the thisMessage BIT STRING are redundant.

The implicit POP is somewhat more elegant.  Encoding an EncryptedValue as a
BIT STRING is a bit of a kludge.

The contradicitory instructions can be reconciled as follows:
If an ArchiveOptions control is included in the certificate request,
implicit POP MAY be indicated by setting thisMessage to an empty BIT STRING.
If thisMessage is empty, an ArchiveOptions control MUST be included in the
certificate request.

Christopher Williams

Software engineer, NetLexis Ltd.
Solutions for secure electronic commerce
http://www.netlexis.com