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

["Brockhaus, Hendrik" <[e-mail]>]

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.