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

[David von Oheimb <[e-mail]>]

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:
>
> 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 <[e-mail]>
> *Gesendet:* Samstag, 9. Oktober 2021 21:07
> *An:* Lijun Liao <[e-mail]>
> *Cc:* Brockhaus, Hendrik (T RDA CST SEA-DE) 
> <[e-mail]>; [e-mail]; von Oheimb, David (T 
> RDA CST SEA-DE) <[e-mail]>; John Gray 
> <[e-mail]>
> *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.
>
> 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 <[e-mail]> wrote:
>
>     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 <[e-mail]>
>     wrote:
>
>
>
>             On Oct 8, 2021, at 12:36 PM, Brockhaus, Hendrik
>             <[e-mail]> 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
>         [e-mail]
>         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
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm