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

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

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Wednesday, October 6, 2021 12:23 PM
To: Brockhaus, Hendrik <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; david.von.oheimb@siemens.com; John Gray <John.Gray@entrust.com>
Subject: [EXTERNAL] Re: [lamps] [CMP Updates] Requesting a current CRL

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
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 <hendrik.brockhaus@siemens.com> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc4210*section-5.3.19.6__;Iw!!FJ-Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-FtMawTzDIEdSOymuy8jpWMedE$ ) 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:hendrik.brockhaus@siemens.com
>
> https://urldefense.com/v3/__http://www.siemens.com__;!!FJ-Y8qCqXTj2!K3
> 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
> Spasm@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-FtMaw
> TzDIEdSOymuy8xYOrR-E$

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-FtMawTzDIEdSOymuy8xYOrR-E$
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.