Subject: [lamps] [CMP Updates] Requesting a current CRL

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 6 Oct 2021 15:53:52 +0000

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:[email-masked]

www.siemens.com

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 6 Oct 2021 12:22:46 -0400

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 <[email-masked]> wrote:
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 7 Oct 2021 14:27:59 +0000

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

      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 <[email-masked]>
> 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 <[email-masked]> On Behalf Of Russ Housley
> Sent: Wednesday, October 6, 2021 12:23 PM
> 
> RFC 4210 says:
> 
> 5.3.19.6.  CRL
> 
> 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
> 
> 
> > 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.
> > 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.
> >
> > Technology - Research in Digitalization and Automation Security
> > Architecture mailto:[email-masked]
> >
> > 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
> >
> > 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$
> 
> 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.

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Oct 2021 13:16:28 -0400

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 <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 8 Oct 2021 05:37:34 +0000

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 <[email-masked]>
> 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
> 
> 
> > 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.
> >
> >> 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
> >> 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
> >>
> >>
> (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.
> >> 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:
> >> 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.
> >>>
> >>> 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
> >>> 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
> >>>
> >>> m__;!!FJ-
> >> 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.
> > 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

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 10:55:09 -0400

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:

	NEW:

Russ

> On Oct 8, 2021, at 1:37 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>

---

From: John Gray <[email-masked]>
Date: Wed, 6 Oct 2021 21:45:03 +0000

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 <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, October 6, 2021 12:23 PM
To: Brockhaus, Hendrik <[email-masked]>
Cc: [email-masked]; [email-masked]; John Gray <[email-masked]>
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

Russ

> 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.
> https://urldefense.com/v3/__http://www.siemens.com__;!!FJ-Y8qCqXTj2!K3
> 2dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-FtMawTzDIEdSOymuy8K9aaZnA$
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-FtMaw
> TzDIEdSOymuy8xYOrR-E$

_______________________________________________
Spasm mailing list
[email-masked]
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.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 8 Oct 2021 15:19:37 +0000

Russ

Thank you for this explanation.

> Gesendet: Freitag, 8. Oktober 2021 16:55
> 
> Hendrik:
> 
>    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:
> 

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

> > 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.
> > 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
> >
> >> 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
> >>
> >>
> >>>  This is used by the EE to inform the CA  about the thisUpdate of
> >>> the  most recent CRL it knows.
> >>>
> >>>  If crlThisUpdate is contained in the generalInfo field of the
> >>> GenMsg, the  CA MUST only return a more current CRL.
> >>>
> >>>> 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
> >>>> 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
> >>>>
> >>>>
> >>>> 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
> >>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> ur
> >>>>> ld
> >>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> ur
> >>>>> ld
> >>>>>
> >>>>
> >>
> >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu
> >>>> rl
> >>>> defens
> >>>>
> >>
> >>>> 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.
> haus%40siemens.com%7C20647c6817d644d3bae008d98a6ba4a6%7C38ae3bcd
> 95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637693017805521807%7CUnknown%7CT
> WFpbGZsb3
> >
> C3000&amp;sdata=4bcIohNWsDgGugoLRr59S7G24wo0fvUjSrJ4HIhdfmw%3D&a
> mp;res
> > erved=0

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 12:10:16 -0400

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 <[email-masked]> wrote:
> 
> Russ
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 8 Oct 2021 16:36:37 +0000

Russ

I am sorry, I feel like I make it too difficult. 
I just want to be on the safe side not to request new OIDs if not really needed.

> Gesendet: Freitag, 8. Oktober 2021 18:10
> 
> Hendrik:
> 
> Option 1B defines a new GenMsgContent, which is also a InfoTypeAndValue.

Yes, I am aware that both use InfoTypeAndValue.

> The difference is that the request and response have two different types, one
> for GenMsg and another one for GenRep.

Yes, this is the proposal of Option 1B.

> 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.

I would consider this as a reasonable behavior. If the server does not understand id-it-crlThisUpdate or if it is absent, the server should respond with the CRL.

My question is, is it OK to reuse id-it-currentCrl together with id-it-crlThisUpdate like this

The server should only answers with <absent> in case the request contained id-it-crlThisUpdate in the generalInfo filed. In this case the client indicates that it knows the updated syntax. Therefore, I thought it is backward compatible.

Do you recommend to define a new OID to be used for this use case instead of id-it-currentCrl, but with using id-it-crlThisUpdate in the generalInfo filed?

 Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 12:39:27 -0400

> On Oct 8, 2021, at 12:36 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 12:40:46 -0400

>    GenRep:    {id-it 6}, CertificateList  |  < absent >

Yes, because <absent> is exactly the same response that would be given if {id-it 6} is unrecognized by the server.

Russ

---

From: Lijun Liao <[email-masked]>
Date: Fri, 8 Oct 2021 22:10:37 +0200

Please also consider the following some complicated scenarios:

1. The CA may have multiple CRLs with different scopes. In RFC 4210, id-it 6
seems to work only for the CA with maximal one CRL scope.

2. The CA may issue full CRL and delta CRLs. Between the period of two full
CRLs, one or more delta CRLs will be issued.

Specifying only thisUpdate does not cover above scenarios, I will suggest to
define a new GenMesage (following the direction of Option B) as follows:

New Section
5.3.19.x Extended CRL Retrieval

CRLGenMsg: {id-it TBD}, ExtendedCRLRetrieval

ExtendedCRLRetrieval ::= SEQUENCE {
   lastCRL    LastCRL OPTIONAL,
              -- the meta data of last CRL known to the client
   crlNumber  INTEGER OPTIONAL
              -- only CRL with this number will be returned
}

LastCRL ::= SEQUENCE {
   thisUpdate          TIME,
   sha256DigestValue   OCTET STRING
                       -- SHA256 Fingerprint of CRL
}

GenRep: {id-it TBD}, SEQUENCE (0..MAX) OF CertificateList
                     -- The CA may have multiple CRLs with different scopes

At the first time, the client sends an ExtendedCRLRetrieval with an empty
SEQUENCE, and the CA returns the current CRLs of all scopes.

For the case without delta CRL, the client sends the following request to
get the current CRL only if it is generated after the lastCRL.

ExtendedCRLRetrieval
   lastCRL
       thisUpdate
       sha256DigestValue

The field sha256DigestValue is needed to identify the scope of CRL.

If the current CRL is a delta CRL, the client has to get the full CRL on
which this delta CRL bases on. It sends the following request:

ExtendedCRLRetrieval
    lastCRL   -- required only if there is more than 1 scope, since
              -- RFC 5280 allows two CRLs with different scopes to have
              -- the same crlNumber
    crlNumber

Since the response is a sequence of CertificateList, option 1A cannot be
applied here.

Lijun

On Fri, Oct 8, 2021 at 6:41 PM Russ Housley <[email-masked]> wrote:

> Yes, because <absent> is exactly the same response that would be given
> if {id-it 6} is unrecognized by the server.
>
> Russ

-- 
Lijun Liao

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Sat, 9 Oct 2021 07:25:46 +0000

Russ

Thank you. Now I got it. :-)

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Freitag, 8. Oktober 2021 18:41
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Cc: [email-masked]; John Gray <[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

On Oct 8, 2021, at 12:36 PM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Sat, 9 Oct 2021 07:31:22 +0000

Hello Lijun

Thank you for describing this use case and solution proposal.
We also discussed briefly the use of delta CRLs in larger environments.
For example in IoT environments CRLs my become quite large and OCSP may not be available.
So it could be, that delta CRLs are a solution here. We just started investigating.

We will discuss you proposal and come back with concrete feedback.

Hendrik

Von: Lijun Liao <[email-masked]>
Gesendet: Freitag, 8. Oktober 2021 22:11
An: Russ Housley <[email-masked]>
Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; [email-masked]; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>; John Gray <[email-masked]>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

New Section

LastCRL ::= SEQUENCE {
   thisUpdate          TIME,

ExtendedCRLRetrieval
   lastCRL
       thisUpdate
       sha256DigestValue

ExtendedCRLRetrieval

Lijun

On Fri, Oct 8, 2021 at 6:41 PM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Russ
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ca4f0e7ceae8647b9e38808d98a97b9f2%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637693206938578404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8HA%2Fi%2F6m4OlV%2Fyo50E9xeoaZSMsMDlqIHRnQZ1o8GTQ%3D&reserved=0>

--
Lijun Liao

---

From: Russ Housley <[email-masked]>
Date: Sat, 9 Oct 2021 15:06:56 -0400

This is an interesting observation, but it does not seem to cover a certificate with multiple CRL distribution points, indirect CRLs, and delta CRLs.  I'm not sure we want all of that complexity here.  That said, it does make sense to me to list a distribution point name and the thisUpdate for each one.

CRLStatusList ::= SEQUENCE OF CRLStatus

CRLStatus ::= SEQUENCE {
   crldpn    DistributionPointName,
   thisUpdate    Time }

CRLs ::= SEQUENCE OF CertificateList

   GenMsg:    {id-it TBD}, CRLStatusList
   GenRep:    {id-it TBD}, CRLs  |  < absent >

Russ

> On Oct 8, 2021, at 4:10 PM, Lijun Liao <[email-masked]> wrote:
> 
> On Fri, Oct 8, 2021 at 6:41 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Oct 8, 2021, at 12:36 PM, Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
> 
> 
> -- 
> Lijun Liao

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 11 Oct 2021 06:28:33 +0000

Russ

Thank you for this proposal. It looks straight forward.
I will need to dig a little deeper into the partitioning of CRLs and check the requirements of our use case for CRL retrieval via CMP to better understand the complexity needed.

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Samstag, 9. Oktober 2021 21:07
An: Lijun Liao <[email-masked]>
Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; [email-masked]; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>; John Gray <[email-masked]>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

CRLStatus ::= SEQUENCE {

Russ

On Oct 8, 2021, at 4:10 PM, Lijun Liao <[email-masked]<mailto:[email-masked]>> wrote:

New Section

LastCRL ::= SEQUENCE {
   thisUpdate          TIME,

ExtendedCRLRetrieval
   lastCRL
       thisUpdate
       sha256DigestValue

ExtendedCRLRetrieval

Lijun

Russ
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C9080fd68d327480c486108d98b57fade%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637694032670329792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C%2FdOQpYcbCwqFEqoy2EbrVhigeEomECxvLXArmDdWs8%3D&reserved=0>

--
Lijun Liao

---

From: David von Oheimb <[email-masked]>
Date: Mon, 11 Oct 2021 17:16:47 +0200

Interesting discussion!

It looks to me that the currently open issue boils down to uniquely 
identifying the (latest) CRL information currently known to the client.
Even when scoped, indirect, and delta CRLs need to be taken into account,
according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3
apparently the following data should be sufficient for unique 
identification:

     CRL issuer, scope, and CRL Number,

or am I missing something?

And how is the scope defined/encoded?
I'm having a hard time getting this nailed down from RFC 5280 and other 
sources,
but according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5
<https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5>it looks 
like the scope is the combination of the following fields:

         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons            [3] ReasonFlags OPTIONAL,
         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

right?

     David

On 11.10.21 08:28, Brockhaus, Hendrik wrote:
> I will need to dig a little deeper into the partitioning of CRLs and 
> check the requirements of our use case for CRL retrieval via CMP to 
> better understand the complexity needed.
>
> Hendrik
>
> *Von:* Russ Housley <[email-masked]>
> *Gesendet:* Samstag, 9. Oktober 2021 21:07
> *An:* Lijun Liao <[email-masked]>
> *Cc:* Brockhaus, Hendrik (T RDA CST SEA-DE) 
> <[email-masked]>; [email-masked]; von Oheimb, David (T 
> RDA CST SEA-DE) <[email-masked]>; John Gray 
> <[email-masked]>
> *Betreff:* Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a 
> current CRL
>
> This is an interesting observation, but it does not seem to cover a 
> certificate with multiple CRL distribution points, indirect CRLs, and 
> delta CRLs.  I'm not sure we want all of that complexity here.  That 
> said, it does make sense to me to list a distribution point name and 
> the thisUpdate for each one.
>
>             My question is, is it OK to reuse id-it-currentCrl
>             together with id-it-crlThisUpdate like this
>
>         Yes, because <absent> is exactly the same response that would
>         be given if {id-it 6} is unrecognized by the server.
>
>         Russ
>
>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C9080fd68d327480c486108d98b57fade%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637694032670329792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C%2FdOQpYcbCwqFEqoy2EbrVhigeEomECxvLXArmDdWs8%3D&reserved=0>
>
>
>
>     -- 
>
>     Lijun Liao
>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Oct 2021 11:25:40 -0400

David:

These flags are clearly part of the scope.  The use of CRL distribution points in certificates can be used to divide the population of certificates across many different CRLs.

Russ

> On Oct 11, 2021, at 11:16 AM, David von Oheimb <[email-masked]> wrote:
> 
> Interesting discussion!
> 
> It looks to me that the currently open issue boils down to uniquely identifying the (latest) CRL information currently known to the client.
> according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3 <https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3>
> apparently the following data should be sufficient for unique identification: 
> 
> I'm having a hard time getting this nailed down from RFC 5280 and other sources, 
>  <https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5>it looks like the scope is the combination of the following fields:
> 
>> Von: Russ Housley <[email-masked]> <mailto:[email-masked]> 
>> An: Lijun Liao <[email-masked]> <mailto:[email-masked]>
>> Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]> <mailto:[email-masked]>; John Gray <[email-masked]> <mailto:[email-masked]>
>> On Oct 8, 2021, at 4:10 PM, Lijun Liao <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C9080fd68d327480c486108d98b57fade%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637694032670329792%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C%2FdOQpYcbCwqFEqoy2EbrVhigeEomECxvLXArmDdWs8%3D&reserved=0>
>> 
>> 
>> -- 
>> Lijun Liao
>>  
>> 
>>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 11 Oct 2021 16:20:25 +0000

Russ

The introduction to Section 5 gives some examples on different scopes.
I du understand how to express theses scopes by using the flags David mentioned.

  *   "all certificates issued by CA X"
  *   "all CA certificates issued by CA X"
  *   "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise",

But I have issues to understand how "all certificates issued to the NIST employees located in Boulder" would be expressed.
Can you give an example?

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Montag, 11. Oktober 2021 17:26
An: David von Oheimb <[email-masked]>
Cc: Lijun Liao <[email-masked]>; [email-masked]; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; John Gray <[email-masked]>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

David:

Russ

On Oct 11, 2021, at 11:16 AM, David von Oheimb <[email-masked]<mailto:[email-masked]>> wrote:

Interesting discussion!
according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504801460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vQVV1IHUgSbjezDqvu%2F01JXhEGZ6Zpnarlmjs3z%2Famg%3D&reserved=0>
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.5&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TfKtJ1iJ1vgi3rDWO9iUC3dr7pyzCpliVbHFEmuFPds%3D&reserved=0>it looks like the scope is the combination of the following fields:

Hendrik

Von: Russ Housley <[email-masked]><mailto:[email-masked]>
Gesendet: Samstag, 9. Oktober 2021 21:07
An: Lijun Liao <[email-masked]><mailto:[email-masked]>
Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]><mailto:[email-masked]>; John Gray <[email-masked]><mailto:[email-masked]>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

CRLStatus ::= SEQUENCE {

Russ

New Section

LastCRL ::= SEQUENCE {
   thisUpdate          TIME,

ExtendedCRLRetrieval
   lastCRL
       thisUpdate
       sha256DigestValue

ExtendedCRLRetrieval

Lijun

Russ
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=saZZx1bqimOUHA9XuVQRKWiZGRQd%2Bb5QkzF6XoI%2FdFc%3D&reserved=0>

--
Lijun Liao

Spasm mailing list

https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0>
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0>

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Oct 2021 14:10:52 -0400

Hendrik:

As the introduction to Section 5 od RFC 5280 says, the scope can be based on "arbitrary local information".  Consider the example that I gave in my earlier response, where a CA uses multiple CRL distribution points.  One distribution point could be associated with NIST employees located in Boulder and a separate distribution point could be for NIST employees in Gaithersburg.  There are certainly other ways to do this, including indirect CRLs, but this is one straightforward approach.

Russ

> On Oct 11, 2021, at 12:20 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>  
> "all certificates issued by CA X"
> "all CA certificates issued by CA X"
> "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise",
>  
> Von: Russ Housley <[email-masked] <mailto:[email-masked]>> 
> An: David von Oheimb <[email-masked] <mailto:[email-masked]>>
> Cc: Lijun Liao <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked] <mailto:[email-masked]>>; John Gray <[email-masked] <mailto:[email-masked]>>
> On Oct 11, 2021, at 11:16 AM, David von Oheimb <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Interesting discussion!
> according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504801460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vQVV1IHUgSbjezDqvu%2F01JXhEGZ6Zpnarlmjs3z%2Famg%3D&reserved=0>
> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=saZZx1bqimOUHA9XuVQRKWiZGRQd%2Bb5QkzF6XoI%2FdFc%3D&reserved=0>
> 
> 
> -- 
> Lijun Liao
>  
> 
> 
> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0>
> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0>
>

---

From: Lijun Liao <[email-masked]>
Date: Mon, 11 Oct 2021 21:26:07 +0200

The URL specified in the extension CRL DP, should be able to identify the
scope.

Russ Housley <[email-masked]> schrieb am Mo., 11. Okt. 2021, 20:11:

> Hendrik:
>
> As the introduction to Section 5 od RFC 5280 says, the scope can be based
> on "arbitrary local information".  Consider the example that I gave in my
> earlier response, where a CA uses multiple CRL distribution points.  One
> distribution point could be associated with NIST employees located in
> Boulder and a separate distribution point could be for NIST employees in
> Gaithersburg.  There are certainly other ways to do this, including
> indirect CRLs, but this is one straightforward approach.
>
> Russ
>
>    - "all certificates issued by CA X"
>    - "all CA certificates issued by CA X"
>    - "all certificates issued by CA X that have been revoked for reasons
>    of key compromise and CA compromise",
>
>
> But I have issues to understand how "all certificates issued to the NIST
> employees located in Boulder" would be expressed.
> Can you give an example?
>
> Hendrik
>
> *Gesendet:* Montag, 11. Oktober 2021 17:26
> *An:* David von Oheimb <[email-masked]>
> *Cc:* Lijun Liao <[email-masked]>; [email-masked]; Brockhaus,
> Hendrik (T RDA CST SEA-DE) <[email-masked]>; John Gray <
> [email-masked]>
> *Betreff:* Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current
> CRL
>
> David:
>
> These flags are clearly part of the scope.  The use of CRL distribution
> points in certificates can be used to divide the population of certificates
> across many different CRLs.
>
> Russ
>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504801460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vQVV1IHUgSbjezDqvu%2F01JXhEGZ6Zpnarlmjs3z%2Famg%3D&reserved=0>
> but according to
> https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.5&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TfKtJ1iJ1vgi3rDWO9iUC3dr7pyzCpliVbHFEmuFPds%3D&reserved=0>it
> looks like the scope is the combination of the following fields:
>
> I will need to dig a little deeper into the partitioning of CRLs and check
> the requirements of our use case for CRL retrieval via CMP to better
> understand the complexity needed.
>
> Hendrik
>
> *Von:* Russ Housley <[email-masked]> <[email-masked]>
> *An:* Lijun Liao <[email-masked]> <[email-masked]>
> <[email-masked]> <[email-masked]>;
> [email-masked]; von Oheimb, David (T RDA CST SEA-DE)
> <[email-masked]> <[email-masked]>; John Gray
> <[email-masked]> <[email-masked]>
> *Betreff:* Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current
> CRL
>
> certificate with multiple CRL distribution points, indirect CRLs, and delta
> CRLs.  I'm not sure we want all of that complexity here.  That said, it
> does make sense to me to list a distribution point name and the thisUpdate
> for each one.
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=saZZx1bqimOUHA9XuVQRKWiZGRQd%2Bb5QkzF6XoI%2FdFc%3D&reserved=0>
>
>
>
> --
> Lijun Liao
>
>
>
>
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0>
>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Oct 2021 15:45:39 -0400

Lijun:

Yes, I agree.  That us the reason for crldpn in the syntax that I suggested.

Russ

> On Oct 11, 2021, at 3:26 PM, Lijun Liao <[email-masked]> wrote:
> 
> The URL specified in the extension CRL DP, should be able to identify the scope.
> 
> 
> Russ Housley <[email-masked] <mailto:[email-masked]>> schrieb am Mo., 11. Okt. 2021, 20:11:
> Hendrik:
> 
>> On Oct 11, 2021, at 12:20 PM, Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Russ
>>

---

From: David von Oheimb <[email-masked]>
Date: Mon, 11 Oct 2021 21:42:51 +0000 (UTC)

So in the end the whole   IssuingDistributionPoint
structure determines the scope.

  David

>> I du understand how to express theses scopes by using the flags David mentioned.
* >> "all certificates issued by CA X"
* >> "all CA certificates issued by CA X"
* >> "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise",
>> *Cc:* Lijun Liao <[email-masked]>; [email-masked]; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; John Gray <[email-masked]>
>> *Betreff:* Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL
>>  
>> David:
>>  
>> according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3[https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504801460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vQVV1IHUgSbjezDqvu%2F01JXhEGZ6Zpnarlmjs3z%2Famg%3D&reserved=0]
>> [https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.5&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TfKtJ1iJ1vgi3rDWO9iUC3dr7pyzCpliVbHFEmuFPds%3D&reserved=0]it looks like the scope is the combination of the following fields:
>> …
>> https://www.ietf.org/mailman/listinfo/spasm[https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0]
>>  
>> _______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>> 
>

---

From: David von Oheimb <[email-masked]>
Date: Tue, 12 Oct 2021 10:11:54 +0200

Thanks for the clarifications.

So how about adapting the CRLStatus part of Russ' below proposal from

CRLStatus ::= SEQUENCE {

to (1):

CRLStatus ::= SEQUENCE {
    scope             IssuingDistributionPoint OPTIONAL,
    thisUpdate    Time }

or to (2):

CRLStatus ::= SEQUENCE {
    issuer            Name,
    cRLNumber  INTEGER,
    scope             IssuingDistributionPoint OPTIONAL }

?

In this way the full scope information can be given if needed, while
for the typical (simple) cases, it should be sufficient to give either 
the thisUpdate value or the CRL issuer and number.

     David

On 11.10.21 21:45, Russ Housley wrote:
>>     As the introduction to Section 5 od RFC 5280 says, the scope can
>>     be based on "arbitrary local information".  Consider the example
>>     that I gave in my earlier response, where a CA uses multiple CRL
>>     distribution points.  One distribution point could be associated
>>     with NIST employees located in Boulder and a separate
>>     distribution point could be for NIST employees in Gaithersburg.
>>     There are certainly other ways to do this, including indirect
>>     CRLs, but this is one straightforward approach.
>>
>>     Russ
>>
>>>       * "all certificates issued by CA X that have been revoked for
>>>         reasons of key compromise and CA compromise",
>>>
>>>     But I have issues to understand how "all certificates issued to
>>>     the NIST employees located in Boulder" would be expressed.
>>>     Can you give an example?
>>>     Hendrik
>>>     *Von:*Russ Housley <[email-masked]>
>>>     *Gesendet:*Montag, 11. Oktober 2021 17:26
>>>     *An:*David von Oheimb <[email-masked]>
>>>     *Cc:*Lijun Liao <[email-masked]>;[email-masked];
>>>     Brockhaus, Hendrik (T RDA CST SEA-DE)
>>>     <[email-masked]>; John Gray <[email-masked]>
>>>     *Betreff:*Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a
>>>     current CRL
>>>     David:
>>>     These flags are clearly part of the scope. The use of CRL
>>>     distribution points in certificates can be used to divide the
>>>     population of certificates across many different CRLs.
>>>     Russ
>>>
>>>
>>>         It looks to me that the currently open issue boils down to
>>>         uniquely identifying the (latest) CRL information currently
>>>         known to the client.
>>>         according
>>>         tohttps://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3
>>>         but according
>>>         tohttps://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5
>>>             I will need to dig a little deeper into the partitioning
>>>             of CRLs and check the requirements of our use case for
>>>             CRL retrieval via CMP to better understand the
>>>             complexity needed.
>>>             Hendrik
>>>             *Von:*Russ Housley<[email-masked]>
>>>             <mailto:[email-masked]>
>>>             *Gesendet:*Samstag, 9. Oktober 2021 21:07
>>>             *An:*Lijun Liao<[email-masked]>
>>>             <mailto:[email-masked]>
>>>             *Cc:*Brockhaus, Hendrik (T RDA CST
>>>             SEA-DE)<[email-masked]>
>>>             <mailto:[email-masked]>;[email-masked];
>>>             von Oheimb, David (T RDA CST
>>>             SEA-DE)<[email-masked]>
>>>             <mailto:[email-masked]>; John
>>>             Gray<[email-masked]> <mailto:[email-masked]>
>>>             *Betreff:*Re: [lamps] [EXTERNAL] Re: [CMP Updates]
>>>             Requesting a current CRL
>>>             This is an interesting observation, but it does not seem
>>>             to cover a certificate with multiple CRL distribution
>>>             points, indirect CRLs, and delta CRLs.  I'm not sure we
>>>             want all of that complexity here.  That said, it does
>>>             make sense to me to list a distribution point name and

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 12 Oct 2021 13:35:24 +0000

Do we really need the whole IssuingDistributionPoint, or is the DistributionPointName sufficient?

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von David von Oheimb
Gesendet: Dienstag, 12. Oktober 2021 10:12
An: Russ Housley <[email-masked]>; Lijun Liao <[email-masked]>
Cc: LAMPS WG <[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>; John Gray <[email-masked]>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

CRLStatus ::= SEQUENCE {

to (1):

CRLStatus ::= SEQUENCE {

or to (2):

CRLStatus ::= SEQUENCE {
   issuer            Name,
   cRLNumber  INTEGER,

?
In this way the full scope information can be given if needed, while
for the typical (simple) cases, it should be sufficient to give either the thisUpdate value or the CRL issuer and number.

    David

  David

Russ

On Oct 11, 2021, at 3:26 PM, Lijun Liao <[email-masked]<mailto:[email-masked]>> wrote:

Russ Housley <[email-masked]<mailto:[email-masked]>> schrieb am Mo., 11. Okt. 2021, 20:11:
Hendrik:

Russ

On Oct 11, 2021, at 12:20 PM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

Russ

Hendrik

Von: Russ Housley <[email-masked]<mailto:[email-masked]>>
Gesendet: Montag, 11. Oktober 2021 17:26
An: David von Oheimb <[email-masked]<mailto:[email-masked]>>
Cc: Lijun Liao <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]<mailto:[email-masked]>>; John Gray <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

David:

Russ

Interesting discussion!
according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C4ad01b5d9113414a477f08d98d580223%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637696232756680209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA%3D&reserved=0>
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.5&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C4ad01b5d9113414a477f08d98d580223%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637696232756690198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Xi1FhU%2BLZ45xBsdwSQPlUPvwF3zIrv0%2F%2FMHy4nr7sm0%3D&reserved=0>it looks like the scope is the combination of the following fields:

Hendrik

CRLStatus ::= SEQUENCE {

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Oct 2021 11:52:34 -0400

With (2), the DistributionPointName can to be included twice.
Also, I would rather name the CRL issuer with GeneralName than Name.
   IssuingDistributionPoint ::= SEQUENCE {
        distributionPoint          [0] DistributionPointName OPTIONAL,
        onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons            [3] ReasonFlags OPTIONAL,
        indirectCRL                [4] BOOLEAN DEFAULT FALSE,
        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
Russ

> On Oct 12, 2021, at 4:11 AM, David von Oheimb <[email-masked]> wrote:
> 
>>> On Oct 11, 2021, at 3:26 PM, Lijun Liao <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: John Gray <[email-masked]>
Date: Tue, 12 Oct 2021 18:06:00 +0000

I think we should only need the DistributionPointName, as we need a way to give the CA the information it needs to be able to lookup the CRL from its internal list of issued CRL's.   I hope this should be enough information for a CA to distinguish which CRL is being requested.  Is this an assumption we should be able to make (that a CA would easily be able to determine a CRL by its DistributionPointName)?

DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

So is this good enough?

CRLStatus ::= SEQUENCE {

In David's (2):
CRLStatus ::= SEQUENCE {
   issuer            Name,
   cRLNumber  INTEGER,

Isn't the Issuer name redundant because we would be making the request to a specific CA (our CMP server), so that should not be needed as we are making a request to the issuer (or an RA acting on behalf of the issuer).   ThisUpdate is needed to indicate to the server to only send a CRL that is newer than the given thisUpdate time (otherwise send nothing).  This should gains the network efficiency we are looking to achieve.  The CRL number is to request specific CRL numbers when all other information is identical.

I like Russ's proposal of supporting multiple CRL's in a CRLStatusList as well (at the expense of a little more complexity).   Supporting CRLStatusList makes it more flexible in case there is a need to request multiple at once.  So I am fine with that flexibility.

Cheers,

John Gray

From: Brockhaus, Hendrik <[email-masked]>
Sent: Tuesday, October 12, 2021 9:35 AM
To: David von Oheimb <[email-masked]>; Russ Housley <[email-masked]>; Lijun Liao <[email-masked]>
Cc: LAMPS WG <[email-masked]>; John Gray <[email-masked]>
Subject: AW: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

Hendrik

Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von David von Oheimb
Gesendet: Dienstag, 12. Oktober 2021 10:12
An: Russ Housley <[email-masked]<mailto:[email-masked]>>; Lijun Liao <[email-masked]<mailto:[email-masked]>>
Cc: LAMPS WG <[email-masked]<mailto:[email-masked]>>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]<mailto:[email-masked]>>; John Gray <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

CRLStatus ::= SEQUENCE {

to (1):

CRLStatus ::= SEQUENCE {

or to (2):

CRLStatus ::= SEQUENCE {
   issuer            Name,
   cRLNumber  INTEGER,

?

    David

  David

Russ

Russ

Russ

Hendrik

David:

Russ

Interesting discussion!
according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3<https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.3&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756680209*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=KqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09vCbUq19$>
<https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.5&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756690198*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=Xi1FhU*2BLZ45xBsdwSQPlUPvwF3zIrv0*2F*2FMHy4nr7sm0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09sF5N2-s$>it looks like the scope is the combination of the following fields:

Hendrik

CRLStatus ::= SEQUENCE {

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Oct 2021 10:51:46 -0400

RFC 5280 defines CRLNumber, and it does not allow negative INTEGER values.

So, I suggest:

CRLStatus ::= SEQUENCE {
   crlnum    CRLNumber,
   thisUpdate    Time }

 
Russ

> On Oct 12, 2021, at 2:06 PM, John Gray <John.Gray=[email-masked]> wrote:
> 
> I think we should only need the DistributionPointName, as we need a way to give the CA the information it needs to be able to lookup the CRL from its internal list of issued CRL’s.   I hope this should be enough information for a CA to distinguish which CRL is being requested.  Is this an assumption we should be able to make (that a CA would easily be able to determine a CRL by its DistributionPointName)?
>  
> In David’s (2):
> Isn’t the Issuer name redundant because we would be making the request to a specific CA (our CMP server), so that should not be needed as we are making a request to the issuer (or an RA acting on behalf of the issuer).   ThisUpdate is needed to indicate to the server to only send a CRL that is newer than the given thisUpdate time (otherwise send nothing).  This should gains the network efficiency we are looking to achieve.  The CRL number is to request specific CRL numbers when all other information is identical.  
>  
> I like Russ’s proposal of supporting multiple CRL’s in a CRLStatusList as well (at the expense of a little more complexity).   Supporting CRLStatusList makes it more flexible in case there is a need to request multiple at once.  So I am fine with that flexibility.
>  
> From: Brockhaus, Hendrik <[email-masked] <mailto:[email-masked]>> 
> To: David von Oheimb <[email-masked] <mailto:[email-masked]>>; Russ Housley <[email-masked] <mailto:[email-masked]>>; Lijun Liao <[email-masked] <mailto:[email-masked]>>
> Cc: LAMPS WG <[email-masked] <mailto:[email-masked]>>; John Gray <[email-masked] <mailto:[email-masked]>>
> Von: Spasm <[email-masked] <mailto:[email-masked]>> Im Auftrag von David von Oheimb
> An: Russ Housley <[email-masked] <mailto:[email-masked]>>; Lijun Liao <[email-masked] <mailto:[email-masked]>>
> Cc: LAMPS WG <[email-masked] <mailto:[email-masked]>>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked] <mailto:[email-masked]>>; John Gray <[email-masked] <mailto:[email-masked]>>
> according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3 <https://urldefense.com/v3/__https:/eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.3&data=04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756680209*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=KqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09vCbUq19$>
> 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

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 13 Oct 2021 16:02:19 +0000

Russ

Thank you for this suggestion. I like it.

While you were sending that email John, David and I were having a meeting discussing the different scenarios we would like to cover.

We see theses two situations:

  *   The client knows a crldpn from its configuration or from a certificates CRLDistributionPoints field. It can use this for all the special cases like Delta CRLs, Indirect CRLs, etc.
  *   If no crldpn is available, the client will know the CA that issues the CRL and would like to get a full CRL covering all certificates issued by this CA.

There are also two additional situations:

  *   The client already has a CRL and knows its thisUpdate time.
  *   The client does not so fare has any CRL from a specific crldpn or CA and therefore does not know any thisUpdate Time.

To be able to also address these situations we suggest his syntax:

CRLStatus ::= SEQUENCE {
   crlSource     CHOICE {
      crldpn          [0] DistributionPointName,
      crlIssuer      [1] GeneralNames
   },
   thisUpdate    Time  OPTIONAL
}

id-it-crlStatusList  OBJECT IDENTIFIER ::= {id-it TBD1}
CRLStatusList ::= SEQUENCE SIZE (1..MAX) OF CRLStatus

id-it-crls  OBJECT IDENTIFIER ::= {id-it TBD2}
CRLs ::= SEQUENCE OF CertificateList

   GenMsg:    {id-it TBD1}, CRLStatusList
   GenRep:    {id-it TBD2}, CRLs  |  < absent >

We also discussed if CRLNumber, but we did not find a case where thisUpdate and a reference to a concrete CRL source is not precise enough.

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Mittwoch, 13. Oktober 2021 16:52

So, I suggest:

CRLStatus ::= SEQUENCE {

Russ

On Oct 12, 2021, at 2:06 PM, John Gray <John.Gray=[email-masked]<mailto:John.Gray=[email-masked]>> wrote:

So is this good enough?

CRLStatus ::= SEQUENCE {

In David's (2):
CRLStatus ::= SEQUENCE {
   issuer            Name,
   cRLNumber  INTEGER,

Cheers,

John Gray

From: Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 12, 2021 9:35 AM
To: David von Oheimb <[email-masked]<mailto:[email-masked]>>; Russ Housley <[email-masked]<mailto:[email-masked]>>; Lijun Liao <[email-masked]<mailto:[email-masked]>>
Cc: LAMPS WG <[email-masked]<mailto:[email-masked]>>; John Gray <[email-masked]<mailto:[email-masked]>>
Subject: AW: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

Hendrik

to (1):
CRLStatus ::= SEQUENCE {

    David

  David

Russ

Russ

Russ

Hendrik

David:

Russ

Interesting discussion!
according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.3%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756680209*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DKqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09vCbUq19%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd0bd97b437a54f3fbfc208d98e590086%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697336668427835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sfMsp2j3U%2BX%2FUOGWCPSNQswKBgOI7jriqbM19%2FPUmXI%3D&reserved=0>
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.5%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756690198*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DXi1FhU*2BLZ45xBsdwSQPlUPvwF3zIrv0*2F*2FMHy4nr7sm0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09sF5N2-s%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd0bd97b437a54f3fbfc208d98e590086%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697336668437830%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mOb2M5dUfnSAM1%2BXCqhNdx%2Fzeg3NVIRQpnmKMqQUCNw%3D&reserved=0>it looks like the scope is the combination of the following fields:

Hendrik

CRLStatus ::= SEQUENCE {

Russ

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd0bd97b437a54f3fbfc208d98e590086%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697336668447824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IEmnM2dzkxU2dFpFUI%2Fvp4ZnWoI6vadrn27%2FHhhP84g%3D&reserved=0>

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Oct 2021 12:08:17 -0400

This is a nit, but I think it is more readable ...

CRLSource ::= CHOICE {
   dpn          [0] DistributionPointName,
   issuer      [1] GeneralNames }

CRLStatus ::= SEQUENCE {
   source    CRLSource,
   thisUpdate    Time }

Russ

> On Oct 13, 2021, at 12:02 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Russ
>  
> The client knows a crldpn from its configuration or from a certificates CRLDistributionPoints field. It can use this for all the special cases like Delta CRLs, Indirect CRLs, etc.
> If no crldpn is available, the client will know the CA that issues the CRL and would like to get a full CRL covering all certificates issued by this CA.
>  
> The client already has a CRL and knows its thisUpdate time.
> The client does not so fare has any CRL from a specific crldpn or CA and therefore does not know any thisUpdate Time.
>  
> On Oct 12, 2021, at 2:06 PM, John Gray <John.Gray=[email-masked] <mailto:John.Gray=[email-masked]>> wrote:
>  
> according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.3%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756680209*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DKqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09vCbUq19%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd0bd97b437a54f3fbfc208d98e590086%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697336668427835%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sfMsp2j3U%2BX%2FUOGWCPSNQswKBgOI7jriqbM19%2FPUmXI%3D&reserved=0>
> https://www.ietf.org/mailman/listinfo/spasm <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cd0bd97b437a54f3fbfc208d98e590086%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697336668447824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IEmnM2dzkxU2dFpFUI%2Fvp4ZnWoI6vadrn27%2FHhhP84g%3D&reserved=0>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 13 Oct 2021 16:12:32 +0000

This is definitely easier to read :-)

Hendrik

Von: Russ Housley <[email-masked]>
Gesendet: Mittwoch, 13. Oktober 2021 18:08

CRLSource ::= CHOICE {

CRLStatus ::= SEQUENCE {
   source    CRLSource,
   thisUpdate    Time }

Russ

On Oct 13, 2021, at 12:02 PM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:

Russ

CRLStatus ::= SEQUENCE {
   crlSource     CHOICE {

Hendrik

So, I suggest:

CRLStatus ::= SEQUENCE {

Russ

So is this good enough?

CRLStatus ::= SEQUENCE {

In David's (2):
CRLStatus ::= SEQUENCE {
   issuer            Name,
   cRLNumber  INTEGER,

Cheers,

John Gray

Hendrik

to (1):
CRLStatus ::= SEQUENCE {

    David

  David

Russ

Russ

Russ

Hendrik

David:

Russ

Interesting discussion!
according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.3%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756680209*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DKqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09vCbUq19%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8b2adc7606c34e9eba3408d98e63b1fb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697381120305096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qvtF5V4a%2B6mLc%2BGJ3bFtGcUD8gpLPRYPFX7L1siYaD4%3D&reserved=0>
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.5%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756690198*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DXi1FhU*2BLZ45xBsdwSQPlUPvwF3zIrv0*2F*2FMHy4nr7sm0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09sF5N2-s%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8b2adc7606c34e9eba3408d98e63b1fb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697381120315091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L8JRl5eDvhhe8%2B7%2BSMQsVex%2FxR9WVQtmXNTyfKE5FK8%3D&reserved=0>it looks like the scope is the combination of the following fields:

Hendrik

CRLStatus ::= SEQUENCE {

Russ

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8b2adc7606c34e9eba3408d98e63b1fb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697381120315091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Abrx4MMtTywrxP0YCDVvqMTeL9kHwTh2RZf2voIbJrU%3D&reserved=0>