RE: draft-ietf-pkix-rfc2510bis-03

[Carlisle Adams <[e-mail]>]

Hi Ari,

> ----------
> From: 	Ari Kermaier[SMTP:[e-mail]]
> Sent: 	Thursday, March 15, 2001 12:35 AM
> To: 	[e-mail]
> Cc: 	Carlisle Adams
> Subject: 	draft-ietf-pkix-rfc2510bis-03
> 
> Dear All,
> 
> I'm seeking clarification of the challenge-response proof-of-possession 
> protocol in CMP. The POP challenge is defined in section 3.2.8 as follows:
> 
>       Challenge ::= SEQUENCE {
>           owf                 AlgorithmIdentifier  OPTIONAL,
>           -- MUST be present in the first Challenge; MAY be omitted in any
>           -- subsequent Challenge in POPODecKeyChallContent (if omitted,
>           -- then the owf used in the immediately preceding Challenge is
>           -- to be used).
>           witness             OCTET STRING,
>           -- the result of applying the one-way function (owf) to a
>           -- randomly-generated INTEGER, A.  [Note that a different
>           -- INTEGER MUST be used for each Challenge.]
>           challenge           OCTET STRING
>           -- the encryption (under the public key for which the cert.
>           -- request is being made) of Rand, where Rand is specified as
>           --   Rand ::= SEQUENCE {
>           --      int      INTEGER,
>           --       - the randomly-generated INTEGER A (above)
>           --      sender   GeneralName
>           --       - the sender's name (as included in PKIHeader)
>           --   }
>       }
> 
> 1) What is the purpose of including the sender's name in the sequence to
> be 
> encrypted? Does it guard against some sort of attack?
 
The easy answer is that all this structure does is encode the protocol given
on page 404 of "Handbook of Applied Cryptography" and, as we are all well
aware, it is unwise to make arbitrary changes to security protocols --
typically, all parameters present in a secure protocol are there for a
reason and should not be removed.

The "real" answer is that this prevents someone else from stealing the
witness and the challenge and presenting them to the receiver as his own
Challenge.  The witness is there to prove that the sender actually did know
the random number beforehand (in order to preclude chosen text attacks), but
it does not provide this value if it can be stolen and presented
successfully by someone else who doesn't know the number.  Therefore, when
the receiver decrypts "challenge", she hashes "int" and matches it up with
"witness", but she also looks at "sender" to verify that it matches up with
the actual sender of the message.

> 2) Since it is quite possible that the DER encoding of the Rand sequence 
> will have length greater than k-11 octets, where k is the length of the
> RSA 
> public modulus (for the RSA key case), what method should be used for 
> performing this encryption and formatting the contents of the challenge 
> OCTET STRING?
 
I don't think Rand will typically be too long to be used for RSA.  The
random integer itself need not be long (64 bits would be lots; even 32 may
be sufficient for this purpose).  Therefore, using a 1024-bit modulus you
would still have well over 100 octets for the "sender" field.  If, in some
environment, names are so long that they really can't fit (e.g., very long
DNs), then perhaps whatever portion will fit should be used (as long as it
includes at least the common name, of course).

> Any help would be most appreciated.
 
Hope this helps!

Carlisle.