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

[Russ Housley <[e-mail]>]

Hendrik:

Option 1A defines a new generalInfo, which is a InfoTypeAndValue.

Option 1B defines a new GenMsgContent, which is also a InfoTypeAndValue.  The difference is that the request and response have two different types, one for GenMsg and another one for GenRep.

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.

Russ

> On Oct 8, 2021, at 11:19 AM, Brockhaus, Hendrik <[e-mail]> wrote:
> 
> Russ
> 
> Thank you for this explanation.
> 
>> Von: Russ Housley <[e-mail]>
>> Gesendet: Freitag, 8. Oktober 2021 16:55
>> 
>> Hendrik:
>> 
>> It is clear to me that either one will work.  The better approach to me depends
>> on the better impact on existing code.
>> 
>> In Option 1A:
>> 
>>   if the client does not send CrlThisUpdate, then the server acts exactly as RFC
>> 4210.
>> 
>>   If the server responds with <absent>, which is not permitted in RFC 4210, it is
>> unclear to me what a client implementation will do.
> 
> The server should only answers with <absent> in case CrlThisUpdate was provided in the request. In this case the client indicates that it knows the updated syntax. Therefore, I thought it is backward compatible.
> 
>> 
>> In Option 1B:
>> 
>>   Section 5.3.19 of RFC 4210 does not offer much assistance; it explains the
>> syntax, but no real help about when <absent> is acceptable or unacceptable.  I
>> do not know how CMP implementations really handle this.  So, defining a new
>> InfoTypeAndValue should avoid concerns with the change:
>> 
>> 	OLD:
>> 
>> 		GenRep: {id-it 6}, CertificateList
>> 
>> 	NEW:
>> 
>> 		GenRep: {id-it 6}, CertificateList  |  < absent >
> 
> I tried to find any indication in the ASN.1 module, but it looks like the ASN.1 module dies not differ if <absent> is allowed or not.
> Your proposal is to define a new OID with this update, right?
> Finally, if you think we should do this to be on the safe side, we could also use it together with CrlThisUpdate.
> I just wanted to prevent to define new ITAV if not necessary.
> 
> Hendrik
> 
>> 
>>> On Oct 8, 2021, at 1:37 AM, Brockhaus, Hendrik
>> <[e-mail]> wrote:
>>> 
>>> Russ
>>> 
>>> You are right. Chaining general messages is not the intend of RFC 4210 Section
>> 5.3.19. Therefore, I agree dropping Option 2.
>>> 
>>> Option 1A and 1B both use a single general message transaction. The
>> difference is how thisUpdate time is provided by the EE.
>>> Option 1A uses the generalInfo field. As I understand you proposal, Option 1B
>> uses the body of the GenMsg.
>>> 
>>> RFC 4210 Section 5.1.1 specifies the generalInfo file like this:
>>> 
>>>  The generalInfo field may be used to send machine-processable
>>>  additional data to the recipient.  The following generalInfo
>>>  extensions are defined and MAY be supported.
>>> 
>>> CMP Updates already specifies two new ITAV to be carried in the generalInfo
>> field in Section 2.4 and 2.5. Theses new ITAV are used in the Lightweight CMP
>> Profile together with general messages. Therefore, I preferer Option 1A using
>> the same approach for requesting CRLs.
>>> 
>>> Hendrik
>>> 
>>>> Von: Russ Housley <[e-mail]>
>>>> Gesendet: Donnerstag, 7. Oktober 2021 19:16
>>>> 
>>>> Hendrik:
>>>> 
>>>> After a quick skim of Section 5.3.19 of RFC 4210, I do not see any
>>>> other uses of PKI General Message Content where the value provided
>>>> with one request has an impact on the response provided by another.  For
>> this reason, I prefer Option 1B.
>>>> 
>>>> Russ
>>>> 
>>>> 
>>>>> On Oct 7, 2021, at 10:27 AM, Brockhaus, Hendrik
>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Thanks to John for his support and to Russ for his proposal.
>>>>> 
>>>>> I had a slightly different approach in mind as Russ described. So I
>>>>> would name
>>>> the approach presented by Russ Option 1B and mine Option 1A.
>>>>> 
>>>>> Option 1A would work like this:
>>>>> 
>>>>> New Section:
>>>>> 5.1.1.X.  CrlThisUpdate
>>>>> 
>>>>> This is used by the EE to inform the CA  about the thisUpdate of
>>>>> the  most recent CRL it knows.
>>>>> 
>>>>>       crlThisUpdate OBJECT IDENTIFIER ::= {id-it TBD}
>>>>>       CrlThisUpdate ::= Time
>>>>> 
>>>>> Updated Section:
>>>>> 5.3.19.6.  CRL
>>>>> 
>>>>> This MAY be used by the client to get a copy of the latest CRL.
>>>>> 
>>>>>    GenMsg:    {id-it 6}, < absent >
>>>>>    GenRep:    {id-it 6}, CertificateList  |  < absent >
>>>>> 
>>>>> If crlThisUpdate is contained in the generalInfo field of the
>>>>> GenMsg, the  CA MUST only return a more current CRL.
>>>>> 
>>>>> Are there any preferences in the WG?
>>>>> 
>>>>> Hendrik
>>>>> 
>>>>>> Von: John Gray <[e-mail]>
>>>>>> Gesendet: Mittwoch, 6. Oktober 2021 23:45
>>>>>> 
>>>>>> Yes, that is exactly what we are suggesting.
>>>>>> 
>>>>>> As you know CRL's can become very large, and it would be a pity to
>>>>>> ask for the latest CRL, only to find out we already had the latest
>>>>>> CRL.  😊 We had also discussed possibly using a hash of the CRL
>>>>>> instead of the time value, but that would cost an extra hash
>>>>>> operation and we agreed thisUpdate should be good enough.  I
>>>>>> wouldn't expect a CA to be fast enough to issue updated CRL's
>>>>>> within
>>>>>> 1 second of each other (thus having the same thisUpdate date).
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> John Gray
>>>>>> 
>>>>>> From: Spasm <[e-mail]> On Behalf Of Russ Housley
>>>>>> Sent: Wednesday, October 6, 2021 12:23 PM
>>>>>> 
>>>>>> RFC 4210 says:
>>>>>> 
>>>>>> 5.3.19.6.  CRL
>>>>>> 
>>>>>> This MAY be used by the client to get a copy of the latest CRL.
>>>>>> 
>>>>>>    GenMsg:    {id-it 6}, < absent >
>>>>>>    GenRep:    {id-it 6}, CertificateList
>>>>>> 
>>>>>> I think you are suggesting something like this for Option 1:
>>>>>> 
>>>>>> 5.3.19.X.  Conditional CRL Retrieval
>>>>>> 
>>>>>> This MAY be used by the client to get a copy of the latest CRL if
>>>>>> a newer one is available.
>>>>>> 
>>>>>>    GenMsg:    {id-it TBD}, Time
>>>>>>    GenRep:    {id-it TBD}, CertificateList | < absent >
>>>>>> 
>>>>>> Where, Time is the thisUpdate of the most recent CRL known to the client.
>>>>>> 
>>>>>> If that is the suggestion, then Option 1 seems to follow the
>>>>>> general design in RFC 4210.  See Section 5.3.19.1 as an example.
>>>>>> 
>>>>>> Russ
>>>>>> 
>>>>>> 
>>>>>>> On Oct 6, 2021, at 11:53 AM, Brockhaus, Hendrik
>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> There are situations where CMP is used on networks that do not
>>>>>>> offer http or
>>>>>> coap, but other transport protocols specified at IEEE or IEC.
>>>>>>> In such case we use the general message as defined in RFC 4210
>>>>>>> Section
>>>>>> 5.3.19.6
>>>>>> 
>>>> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
>>>> tatrac
>>>> ker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-
>>>> 
>> 5.3.19.6&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2a1f8
>>>> 
>> 11b31124e63d01b08d989b63743%7C38ae3bcd95794fd4addab42e1495d55a%7
>>>> 
>> C1%7C0%7C637692238717449200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>>>> 
>> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
>>>> 
>> mp;sdata=4E9ffpU0dgD29BYAx9rqOX5tN0ObW1X7dsALJd3EABI%3D&amp;reser
>>>> ved=0) for requesting CRLs.
>>>>>>> Currently the CMP server always send its most current CRL,
>>>>>>> regardless if the
>>>>>> CMP client already has this CRL.
>>>>>>> To avoid sending the same CRL multiple times, we would like to
>>>>>>> extend the
>>>>>> mechanism sending only more current CRLs than the CMP client already
>> has.
>>>>>>> 
>>>>>>> Together with John Gray from Entrust, who we also like to add as
>>>>>>> co-author to
>>>>>> the CMP Updates Draft, we discussed mainly two implementation options.
>>>>>>> 
>>>>>>> Option 1:
>>>>>>> Define a new generalInfo field to be provided in the request
>>>>>>> messages header
>>>>>> of the general message specified in RFC 4210 Section 5.3.19.6. This
>>>>>> ITAV shall contain the thisUpdate time of the most current CRL the
>>>>>> CMP client has. The CMP server shall return its CRL if it is more
>>>>>> current and otherwise with an empty body.
>>>>>>> 
>>>>>>> Option 2:
>>>>>>> Define a new general message type. Sending this new general
>>>>>>> message, the
>>>>>> CMP client requests the thisUpdate time of the most current CRL the
>>>>>> CMP server has. If this is more current than the most current CRL
>>>>>> the CMP client has, it requests this CRL using the general message
>>>>>> specified in RFC 4210 Section 5.3.19.6.
>>>>>>> 
>>>>>>> The authors would prefer option 1. What is the opinion of the WG?
>>>>>>> 
>>>>>>> BTW, this is the last open issue of this draft. The authors hope
>>>>>>> that the next
>>>>>> update will be the last before WGLC.
>>>>>>> 
>>>>>>> Hendrik
>>>>>>> 
>>>>>>> 
>>>>>>> Siemens AG
>>>>>>> Technology - Research in Digitalization and Automation Security
>>>>>>> Architecture mailto:[e-mail]
>>>>>>> 
>>>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>> ur
>>>>>>> ld
>>>>>>> efense.com%2Fv3%2F__http%3A%2F%2Fwww.siemens.com__%3B!!FJ-
>>>>>> Y8qCqXTj2!K3
>>>>>>> 
>>>>>> 
>>>> 
>> &amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cd8c2a53f27
>>>>>> 42e2
>>>>>>> 
>>>>>> 
>>>> 
>> 6fac08d9891291b7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63
>>>>>> 769153
>>>>>>> 
>>>>>> 
>>>> 
>> 5123328589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>>>> V2luMzI
>>>>>>> 
>>>>>> 
>>>> 
>> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Wzag2sbqWIEuWaJ
>>>>>> 4tUuNi
>>>>>>> VokUg6Bb%2BdDq7OyXroN43k%3D&amp;reserved=0
>>>>>>> 2dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-
>>>>>> FtMawTzDIEdSOymuy8K9aaZnA$
>>>>>>> 
>>>>>>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
>>>>>>> Hagemann Snabe; Managing Board: Roland Busch, Chairman, President
>>>>>>> and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P.
>>>>>>> Thomas, Judith Wiese; Registered offices: Berlin and Munich,
>>>>>>> Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300,
>>>>>>> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Spasm mailing list
>>>>>>> [e-mail]
>>>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>> ur
>>>>>>> ld
>>>>>>> 
>>>>>> 
>>>> 
>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo
>>>>>> %2F
>>>>>>> 
>>>>>> 
>>>> 
>> spas&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cd8c2a5
>>>>>> 3f27
>>>>>>> 
>>>>>> 
>>>> 
>> 42e26fac08d9891291b7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
>>>>>> 7C6376
>>>>>>> 
>>>>>> 
>>>> 
>> 91535123328589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
>>>>>> QIjoiV2l
>>>>>>> 
>>>>>> 
>>>> 
>> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sWEzRWabxIrH
>>>>>> U2Ry4
>>>>>>> 2sy2YZewT7kDNOq1lIMP9ymOAE%3D&amp;reserved=0
>>>>>>> m__;!!FJ-
>>>> Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-
>>>>>> FtMaw
>>>>>>> TzDIEdSOymuy8xYOrR-E$
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Spasm mailing list
>>>>>> [e-mail]
>>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu
>>>>>> rl
>>>>>> defens
>>>>>> 
>>>> 
>> e.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsp
>>>>>> asm__%3B!!FJ-
>>>>>> Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-
>>>>>> FtMawTzDIEdSOymuy8xYOrR-
>>>>>> 
>>>> 
>> E%24&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cd8c2a
>>>>>> 
>>>> 
>> 53f2742e26fac08d9891291b7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
>>>>>> 
>>>> 
>> 7C0%7C637691535123328589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>> 
>>>> 
>> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
>>>>>> 
>>>> 
>> data=mZrMYo45HQGV0FLd8f6TfQKNLgeS0s420sJpXUvaVVM%3D&amp;reserve
>>>>>> d=0
>>>>>> Any email and files/attachments transmitted with it are
>>>>>> confidential and are intended solely for the use of the individual
>>>>>> or entity to whom they are addressed. If this message has been sent
>>>>>> to you in error, you must not copy, distribute or disclose of the
>>>>>> information it contains. Please notify Entrust immediately and
>>>>>> delete the message from
>>>> your system.
>>>>> _______________________________________________
>>>>> Spasm mailing list
>>>>> [e-mail]
>>>>> 
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>>>> 
>>>> 
>> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.broc
>>>> k
>>>>> 
>>>> 
>> haus%40siemens.com%7C2a1f811b31124e63d01b08d989b63743%7C38ae3bcd
>>>> 95794f
>>>>> 
>>>> 
>> d4addab42e1495d55a%7C1%7C0%7C637692238717459201%7CUnknown%7CT
>>>> WFpbGZsb3
>>>>> 
>>>> 
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>>>> D%7
>>>>> 
>>>> 
>> C3000&amp;sdata=XdAzbm5lVFFCWz0bC0FmrwJT3APVOChsXe4SAZa5LkE%3D&
>>>> amp;res
>>>>> erved=0
>>> 
>>> _______________________________________________
>>> Spasm mailing list
>>> [e-mail]
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>>> 
>> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.broc
>> k
>>> 
>> haus%40siemens.com%7C20647c6817d644d3bae008d98a6ba4a6%7C38ae3bcd
>> 95794f
>>> 
>> d4addab42e1495d55a%7C1%7C0%7C637693017805521807%7CUnknown%7CT
>> WFpbGZsb3
>>> 
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>> D%7
>>> 
>> C3000&amp;sdata=4bcIohNWsDgGugoLRr59S7G24wo0fvUjSrJ4HIhdfmw%3D&a
>> mp;res
>>> erved=0
>