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

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

Russ

Thank you for this explanation.

> Von: Russ Housley <[e-mail]>
> Gesendet: Freitag, 8. Oktober 2021 16:55
> 
> 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.

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:
> 
> 		GenRep: {id-it 6}, CertificateList
> 
> 	NEW:
> 
> 		GenRep: {id-it 6}, CertificateList  |  < absent >

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

> 
> > On Oct 8, 2021, at 1:37 AM, Brockhaus, Hendrik
> <[e-mail]> wrote:
> >
> > Russ
> >
> > You are right. Chaining general messages is not the intend of RFC 4210 Section
> 5.3.19. Therefore, I agree dropping Option 2.
> >
> > Option 1A and 1B both use a single general message transaction. The
> difference is how thisUpdate time is provided by the EE.
> > Option 1A uses the generalInfo field. As I understand you proposal, Option 1B
> uses the body of the GenMsg.
> >
> > RFC 4210 Section 5.1.1 specifies the generalInfo file like this:
> >
> >   The generalInfo field may be used to send machine-processable
> >   additional data to the recipient.  The following generalInfo
> >   extensions are defined and MAY be supported.
> >
> > CMP Updates already specifies two new ITAV to be carried in the generalInfo
> field in Section 2.4 and 2.5. Theses new ITAV are used in the Lightweight CMP
> Profile together with general messages. Therefore, I preferer Option 1A using
> the same approach for requesting CRLs.
> >
> > Hendrik
> >
> >> Von: Russ Housley <[e-mail]>
> >> Gesendet: Donnerstag, 7. Oktober 2021 19:16
> >>
> >> Hendrik:
> >>
> >> After a quick skim of Section 5.3.19 of RFC 4210, I do not see any
> >> other uses of PKI General Message Content where the value provided
> >> with one request has an impact on the response provided by another.  For
> this reason, I prefer Option 1B.
> >>
> >> Russ
> >>
> >>
> >>> On Oct 7, 2021, at 10:27 AM, Brockhaus, Hendrik
> >> <[e-mail]> wrote:
> >>>
> >>> Thanks to John for his support and to Russ for his proposal.
> >>>
> >>> I had a slightly different approach in mind as Russ described. So I
> >>> would name
> >> the approach presented by Russ Option 1B and mine Option 1A.
> >>>
> >>> Option 1A would work like this:
> >>>
> >>> New Section:
> >>> 5.1.1.X.  CrlThisUpdate
> >>>
> >>>  This is used by the EE to inform the CA  about the thisUpdate of
> >>> the  most recent CRL it knows.
> >>>
> >>>        crlThisUpdate OBJECT IDENTIFIER ::= {id-it TBD}
> >>>        CrlThisUpdate ::= Time
> >>>
> >>> Updated Section:
> >>> 5.3.19.6.  CRL
> >>>
> >>>  This MAY be used by the client to get a copy of the latest CRL.
> >>>
> >>>     GenMsg:    {id-it 6}, < absent >
> >>>     GenRep:    {id-it 6}, CertificateList  |  < absent >
> >>>
> >>>  If crlThisUpdate is contained in the generalInfo field of the
> >>> GenMsg, the  CA MUST only return a more current CRL.
> >>>
> >>> Are there any preferences in the WG?
> >>>
> >>> Hendrik
> >>>
> >>>> Von: John Gray <[e-mail]>
> >>>> Gesendet: Mittwoch, 6. Oktober 2021 23:45
> >>>>
> >>>> Yes, that is exactly what we are suggesting.
> >>>>
> >>>> As you know CRL's can become very large, and it would be a pity to
> >>>> ask for the latest CRL, only to find out we already had the latest
> >>>> CRL.  😊 We had also discussed possibly using a hash of the CRL
> >>>> instead of the time value, but that would cost an extra hash
> >>>> operation and we agreed thisUpdate should be good enough.  I
> >>>> wouldn't expect a CA to be fast enough to issue updated CRL's
> >>>> within
> >>>> 1 second of each other (thus having the same thisUpdate date).
> >>>>
> >>>> Cheers,
> >>>>
> >>>> John Gray
> >>>>
> >>>> From: Spasm <[e-mail]> On Behalf Of Russ Housley
> >>>> Sent: Wednesday, October 6, 2021 12:23 PM
> >>>>
> >>>> RFC 4210 says:
> >>>>
> >>>> 5.3.19.6.  CRL
> >>>>
> >>>>  This MAY be used by the client to get a copy of the latest CRL.
> >>>>
> >>>>     GenMsg:    {id-it 6}, < absent >
> >>>>     GenRep:    {id-it 6}, CertificateList
> >>>>
> >>>> I think you are suggesting something like this for Option 1:
> >>>>
> >>>> 5.3.19.X.  Conditional CRL Retrieval
> >>>>
> >>>>  This MAY be used by the client to get a copy of the latest CRL if
> >>>> a newer one is available.
> >>>>
> >>>>     GenMsg:    {id-it TBD}, Time
> >>>>     GenRep:    {id-it TBD}, CertificateList | < absent >
> >>>>
> >>>> Where, Time is the thisUpdate of the most recent CRL known to the client.
> >>>>
> >>>> If that is the suggestion, then Option 1 seems to follow the
> >>>> general design in RFC 4210.  See Section 5.3.19.1 as an example.
> >>>>
> >>>> Russ
> >>>>
> >>>>
> >>>>> On Oct 6, 2021, at 11:53 AM, Brockhaus, Hendrik
> >>>> <[e-mail]> wrote:
> >>>>>
> >>>>> There are situations where CMP is used on networks that do not
> >>>>> offer http or
> >>>> coap, but other transport protocols specified at IEEE or IEC.
> >>>>> In such case we use the general message as defined in RFC 4210
> >>>>> Section
> >>>> 5.3.19.6
> >>>>
> >> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> >> tatrac
> >> ker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-
> >>
> 5.3.19.6&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2a1f8
> >>
> 11b31124e63d01b08d989b63743%7C38ae3bcd95794fd4addab42e1495d55a%7
> >>
> C1%7C0%7C637692238717449200%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&a
> >>
> mp;sdata=4E9ffpU0dgD29BYAx9rqOX5tN0ObW1X7dsALJd3EABI%3D&amp;reser
> >> ved=0) for requesting CRLs.
> >>>>> Currently the CMP server always send its most current CRL,
> >>>>> regardless if the
> >>>> CMP client already has this CRL.
> >>>>> To avoid sending the same CRL multiple times, we would like to
> >>>>> extend the
> >>>> mechanism sending only more current CRLs than the CMP client already
> has.
> >>>>>
> >>>>> Together with John Gray from Entrust, who we also like to add as
> >>>>> co-author to
> >>>> the CMP Updates Draft, we discussed mainly two implementation options.
> >>>>>
> >>>>> Option 1:
> >>>>> Define a new generalInfo field to be provided in the request
> >>>>> messages header
> >>>> of the general message specified in RFC 4210 Section 5.3.19.6. This
> >>>> ITAV shall contain the thisUpdate time of the most current CRL the
> >>>> CMP client has. The CMP server shall return its CRL if it is more
> >>>> current and otherwise with an empty body.
> >>>>>
> >>>>> Option 2:
> >>>>> Define a new general message type. Sending this new general
> >>>>> message, the
> >>>> CMP client requests the thisUpdate time of the most current CRL the
> >>>> CMP server has. If this is more current than the most current CRL
> >>>> the CMP client has, it requests this CRL using the general message
> >>>> specified in RFC 4210 Section 5.3.19.6.
> >>>>>
> >>>>> The authors would prefer option 1. What is the opinion of the WG?
> >>>>>
> >>>>> BTW, this is the last open issue of this draft. The authors hope
> >>>>> that the next
> >>>> update will be the last before WGLC.
> >>>>>
> >>>>> Hendrik
> >>>>>
> >>>>>
> >>>>> Siemens AG
> >>>>> Technology - Research in Digitalization and Automation Security
> >>>>> Architecture mailto:[e-mail]
> >>>>>
> >>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> ur
> >>>>> ld
> >>>>> efense.com%2Fv3%2F__http%3A%2F%2Fwww.siemens.com__%3B!!FJ-
> >>>> Y8qCqXTj2!K3
> >>>>>
> >>>>
> >>
> &amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cd8c2a53f27
> >>>> 42e2
> >>>>>
> >>>>
> >>
> 6fac08d9891291b7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63
> >>>> 769153
> >>>>>
> >>>>
> >>
> 5123328589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> >>>> V2luMzI
> >>>>>
> >>>>
> >>
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Wzag2sbqWIEuWaJ
> >>>> 4tUuNi
> >>>>> VokUg6Bb%2BdDq7OyXroN43k%3D&amp;reserved=0
> >>>>> 2dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-
> >>>> FtMawTzDIEdSOymuy8K9aaZnA$
> >>>>>
> >>>>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> >>>>> Hagemann Snabe; Managing Board: Roland Busch, Chairman, President
> >>>>> and Chief Executive Officer; Cedrik Neike, Matthias Rebellius, Ralf P.
> >>>>> Thomas, Judith Wiese; Registered offices: Berlin and Munich,
> >>>>> Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300,
> >>>>> Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> >>>>>
> >>>>> _______________________________________________
> >>>>> Spasm mailing list
> >>>>> [e-mail]
> >>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>> ur
> >>>>> ld
> >>>>>
> >>>>
> >>
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo
> >>>> %2F
> >>>>>
> >>>>
> >>
> spas&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cd8c2a5
> >>>> 3f27
> >>>>>
> >>>>
> >>
> 42e26fac08d9891291b7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> >>>> 7C6376
> >>>>>
> >>>>
> >>
> 91535123328589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> >>>> QIjoiV2l
> >>>>>
> >>>>
> >>
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sWEzRWabxIrH
> >>>> U2Ry4
> >>>>> 2sy2YZewT7kDNOq1lIMP9ymOAE%3D&amp;reserved=0
> >>>>> m__;!!FJ-
> >> Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-
> >>>> FtMaw
> >>>>> TzDIEdSOymuy8xYOrR-E$
> >>>>
> >>>> _______________________________________________
> >>>> Spasm mailing list
> >>>> [e-mail]
> >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fu
> >>>> rl
> >>>> defens
> >>>>
> >>
> e.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsp
> >>>> asm__%3B!!FJ-
> >>>> Y8qCqXTj2!K32dsgB2GqHGjdnUPkY_QKkcXyA_WG_c9clb1EI8fIW05-
> >>>> FtMawTzDIEdSOymuy8xYOrR-
> >>>>
> >>
> E%24&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cd8c2a
> >>>>
> >>
> 53f2742e26fac08d9891291b7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> >>>>
> >>
> 7C0%7C637691535123328589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> >>>>
> >>
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> >>>>
> >>
> data=mZrMYo45HQGV0FLd8f6TfQKNLgeS0s420sJpXUvaVVM%3D&amp;reserve
> >>>> d=0
> >>>> Any email and files/attachments transmitted with it are
> >>>> confidential and are intended solely for the use of the individual
> >>>> or entity to whom they are addressed. If this message has been sent
> >>>> to you in error, you must not copy, distribute or disclose of the
> >>>> information it contains. Please notify Entrust immediately and
> >>>> delete the message from
> >> your system.
> >>> _______________________________________________
> >>> Spasm mailing list
> >>> [e-mail]
> >>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >>>
> >>
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.broc
> >> k
> >>>
> >>
> haus%40siemens.com%7C2a1f811b31124e63d01b08d989b63743%7C38ae3bcd
> >> 95794f
> >>>
> >>
> d4addab42e1495d55a%7C1%7C0%7C637692238717459201%7CUnknown%7CT
> >> WFpbGZsb3
> >>>
> >>
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> >> D%7
> >>>
> >>
> C3000&amp;sdata=XdAzbm5lVFFCWz0bC0FmrwJT3APVOChsXe4SAZa5LkE%3D&
> >> amp;res
> >>> erved=0
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://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%7C20647c6817d644d3bae008d98a6ba4a6%7C38ae3bcd
> 95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637693017805521807%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7
> >
> C3000&amp;sdata=4bcIohNWsDgGugoLRr59S7G24wo0fvUjSrJ4HIhdfmw%3D&a
> mp;res
> > erved=0