Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

[Russ Housley <[e-mail]>]

> On Oct 8, 2021, at 12:36 PM, Brockhaus, Hendrik <[e-mail]> wrote:
> 
> Russ
> 
> I am sorry, I feel like I make it too difficult. 
> I just want to be on the safe side not to request new OIDs if not really needed.
> 
>> Von: Russ Housley <[e-mail]>
>> Gesendet: Freitag, 8. Oktober 2021 18:10
>> 
>> Hendrik:
>> 
>> Option 1A defines a new generalInfo, which is a InfoTypeAndValue.
>> 
>> Option 1B defines a new GenMsgContent, which is also a InfoTypeAndValue.
> 
> Yes, I am aware that both use InfoTypeAndValue.
> 
>> The difference is that the request and response have two different types, one
>> for GenMsg and another one for GenRep.
> 
> Yes, this is the proposal of Option 1B.
> 
>> 
>> The only hint that I find regarding the :
>> 
>> -- Receiver MAY ignore any contained OIDs that it does not
>> -- recognize.
>> 
>> This tells me that in Option 1A, the server can ignore the new generalInfo that
>> provides the CrlThisUpdate, and then always provide the full CRL in the CRL
>> GenRep.
> 
> I would consider this as a reasonable behavior. If the server does not understand id-it-crlThisUpdate or if it is absent, the server should respond with the CRL.
> 
> My question is, is it OK to reuse id-it-currentCrl together with id-it-crlThisUpdate like this
> 
>    GenMsg:    {id-it 6}, < absent >
>    GenRep:    {id-it 6}, CertificateList  |  < absent >
> 
> The server should only answers with <absent> in case the request contained id-it-crlThisUpdate in the generalInfo filed. In this case the client indicates that it knows the updated syntax. Therefore, I thought it is backward compatible.
> 
> Do you recommend to define a new OID to be used for this use case instead of id-it-currentCrl, but with using id-it-crlThisUpdate in the generalInfo filed?
> 
> Hendrik