Re: Two questions about 2510 from interop trials

[tgindin@xxxxxxxxxx]

     If the sender name is there as a check, why not allow a hash of the sender
name as an option in these cases (see below)?

          Tom Gindin

Keith Brady <keith@baltimore.ie> on 07/22/99 04:58:47 PM

To:   ietf-pkix@imc.org
cc:
Subject:  Two questions about 2510 from interop trials






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).

[Tom Gindin]   How about making sender in Challenge.Rand the following:

sender    CHOICE    {
     name      GeneralName,   -- must match PKIHeader.sender
     hash      SenderHash
}

SenderHash     ::=  SEQUENCE  {
     algorithm AlgorithmIdentifier,
     hashValue OCTET STRING   -- taken on PKIHeader.sender
}

[Tom Gindin]   Naturally, sender.hash (whose normal size would be about 35
bytes) would be used whenever the length of Rand using the name format would
exceed one encryption block.


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