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

[Russ Housley <[e-mail]>]

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://datatracker.ietf.org/doc/html/rfc4210#section-5.3.19.6) 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%2Furld
>>> 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%2Furld
>>> 
>> 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%2Furldefens
>> 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://www.ietf.org/mailman/listinfo/spasm