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

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 <lijun.liao@gmail.com>
Gesendet: Freitag, 8. Oktober 2021 22:11
An: Russ Housley <housley@vigilsec.com>
Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com>; spasm@ietf.org; von Oheimb, David (T RDA CST SEA-DE) <david.von.oheimb@siemens.com>; John Gray <John.Gray@entrust.com>
Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL

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 <housley@vigilsec.com<mailto:housley@vigilsec.com>> wrote:

On Oct 8, 2021, at 12:36 PM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>> wrote:

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

   GenMsg:    {id-it 6}, < absent >
   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
_______________________________________________
Spasm mailing list
Spasm@ietf.org<mailto:Spasm@ietf.org>
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