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

[Russ Housley <[e-mail]>]

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.

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 >

Russ

> 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%2Fdatatrac
>> 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%2Fur
>>>>> 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%2Fur
>>>>> 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%2Furl
>>>> 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://www.ietf.org/mailman/listinfo/spasm