Two questions about 2510 from interop trials

[Keith Brady <keith@xxxxxxxxxxxx>]

As I mentioned in Oslo there are a couple of additional questions about
rfc2510 that have come up as we prepare for the next CMP interop workshops.

1) Polling Time

In section 5.2 (TCP direct protocol), the time-to-check-back is in epoch
seconds. Since there is no guarantee that the CA/RA and end-entity have
properly synchronised clocks and since we want to avoid the Y2038 issue it
was the opinion of the last workshop attendees that this should be changed
to be a delta from when the CA/RA issues the pollRep partialMsgRep.

Is this a good idea and should it be in a rev of 2510?

[I believe this point was first raised by John Wray of Iris]

2) Proof of Possession of Encryption Key

[Note: I do not query the need for this and have no wish to reactivate the
       rather tired argument about it]

It will be a goal of future interops to handle POP on encryption keys.
There appears to be an odd quirk in section 3.2.8 option 3 where the input
to the encryption process -- Challenge.Rand -- is reasonably likely to be
larger than the block size of the key in question (for example, if
Challenge.Rand.sender is a distinguished name of reasonable depth and the
key is a 1024-bit one).

Clearly this has performancce implications and since PKCS-1 ('93) does not
explain how to do RSA encryption where more than one block is required
there is some chance (however slim) that implementations will do this
incorrectly.

Should we deprecate this option or amend Challenge to use EncryptedValue
(for example)?


cheers,

Keith