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

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 <rdd@cert.org> wrote:
> 
> 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 <hendrik.brockhaus@siemens.com>
>> Sent: Monday, November 15, 2021 10:32 AM
>> To: Russ Housley <housley@vigilsec.com>; Roman Danyliw <rdd@cert.org>
>> Cc: LAMPS WG <spasm@ietf.org>; david.von.oheimb@siemens.com; John Gray
>> <John.Gray@entrust.com>
>> 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 <housley@vigilsec.com>
>>> 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 }
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm