Subject: Re: [lamps] Allocation of OIDs for CRL update retrieval (draft-ietf-lamps-cmp-updates-13)

From: Roman Danyliw <[email-masked]>
Date: Thu, 13 Jan 2022 16:25:59 +0000

Hi!

With apologies, I missed this request and took no action on requesting early allocation.  I see that draft-ietf-lamps-cmp-updates-17 moved to the "Publication Requested" state yesterday.  Does the WG want me to pick-up this early allocation request or is it acceptable to wait until the document move through the normal process?

If the WG wants early allocation to move as fast as possible, could I please get a pointer to demonstrate WG consensus on this allocation per Step #3 of Section 3.1 of RFC 7120.  I wasn't able to find that consensus in the IETF 112 meeting minutes that I believe are the reference noted below as "As discussed on Monday, ..."

Roman

> -----Original Message-----
> From: Brockhaus, Hendrik <[email-masked]>
> Sent: Monday, November 15, 2021 10:32 AM
> To: Russ Housley <[email-masked]>; Roman Danyliw <[email-masked]>
> Cc: LAMPS WG <[email-masked]>; [email-masked]; John Gray
> <[email-masked]>
> Subject: AW: Allocation of OIDs for CRL update retrieval (draft-ietf-lamps-cmp-
> updates-13)
> 
> Russ
> 
> Thank you for starting the registration.
> As soon as the OIDs are assigned, I will add them to the document.
> 
> Hendrik
> 
> > Von: Russ Housley <[email-masked]>
> > Gesendet: Mittwoch, 10. November 2021 22:26
> >
> > Roman:
> >
> > As discussed on Monday, the LAMPS WG would like to get early
> > (permanent) allocation of two OIDs from IANA.
> >
> > The relevant part of draft-ietf-lamps-cmp-updates-13 is quoted below.
> >
> > The OID need to be allocated in SMI Security for PKIX CMP Information
> > Types (1.3.6.1.5.5.7.4).
> > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > iana.org%2Fassignments%2Fsmi-numbers%2Fsmi-numbers.xml%23smi-
> > numbers-
> >
> 1.3.6.1.5.5.7.4&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%
> >
> 7Ce429a066d36b4f2cf3da08d9a490ab14%7C38ae3bcd95794fd4addab42e149
> >
> 5d55a%7C1%7C0%7C637721763514579270%7CUnknown%7CTWFpbGZsb3d8
> >
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> >
> %7C1000&amp;sdata=9g3dUqOyT2qDNXWCBgw%2B7szmus2EI4jLWp0HTGC0
> > zIM%3D&amp;reserved=0)
> >
> > Thanks,
> >   Russ
> >
> > = = = = = = = = =
> > 2.16.  New Section 5.3.19.17 - CRL update retrieval
> >
> >    The following subsection introduces the PKI general message using id-
> >    it-crlStatusList and id-it-crls.  Details are specified in the
> >    Lightweight CMP Profile Section 4.3
> >    [I-D.ietf-lamps-lightweight-cmp-profile].  Insert this section after
> >    new Section 5.3.19.16:
> >
> >    5.3.19.17.  CRL update retrieval
> >
> >    This MAY be used by the client to get new CRLs, specifying the source
> >    of the CRLs and the thisUpdate value of the latest CRL it already
> >    has, if available.  A CRL source is given either by a
> >    DistributionPointName or the GeneralNames of the issuing CA.  The
> >    server shall provide only those CRLs that are more recent than the
> >    ones indicated by the client.
> >
> >       GenMsg:    {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus
> >       GenRep:    {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF
> >                                CertificateList  |  < absent >
> >
> >       CRLSource ::= CHOICE {
> >          dpn          [0] DistributionPointName,
> >          issuer       [1] GeneralNames }
> >
> >       CRLStatus ::= SEQUENCE {
> >          source       CRLSource,
> >          thisUpdate   Time OPTIONAL }

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Jan 2022 12:21:20 -0500

Roman:

I think we can get the OIDs as the document goes through the approval process.

Russ

> On Jan 13, 2022, at 11:25 AM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 13 Jan 2022 21:29:33 +0000

Hi Russ: Understood.  I won't take any action.

WG: Again, sorry for letting this slip.

Roman

> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Thursday, January 13, 2022 12:21 PM
> To: Roman Danyliw <[email-masked]>
> Cc: LAMPS <[email-masked]>; John Gray <[email-masked]>;
> [email-masked]; Brockhaus, Hendrik
> <[email-masked]>
> Subject: Re: [lamps] Allocation of OIDs for CRL update retrieval (draft-ietf-
> lamps-cmp-updates-13)
> 
> Roman:
> 
> > With apologies, I missed this request and took no action on requesting early
> allocation.  I see that draft-ietf-lamps-cmp-updates-17 moved to the
> "Publication Requested" state yesterday.  Does the WG want me to pick-up this
> early allocation request or is it acceptable to wait until the document move
> through the normal process?
> >
> > If the WG wants early allocation to move as fast as possible, could I please get
> a pointer to demonstrate WG consensus on this allocation per Step #3 of
> Section 3.1 of RFC 7120.  I wasn't able to find that consensus in the IETF 112
> meeting minutes that I believe are the reference noted below as "As discussed
> on Monday, ..."
> >
> > Roman
> >
> >> Cc: LAMPS WG <[email-masked]>; [email-masked]; John
> >> Gray <[email-masked]>
> >>> The OID need to be allocated in SMI Security for PKIX CMP
> >>> Information Types (1.3.6.1.5.5.7.4).
> >>>