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

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

Thanks for the clarifications.

So how about adapting the CRLStatus part of Russ' below proposal from

CRLStatus ::= SEQUENCE {
    crldpn    DistributionPointName,
    thisUpdate    Time }

to (1):

CRLStatus ::= SEQUENCE {
    scope             IssuingDistributionPoint OPTIONAL,
    thisUpdate    Time }

or to (2):

CRLStatus ::= SEQUENCE {
    issuer            Name,
    cRLNumber  INTEGER,
    scope             IssuingDistributionPoint OPTIONAL }

?

In this way the full scope information can be given if needed, while
for the typical (simple) cases, it should be sufficient to give either 
the thisUpdate value or the CRL issuer and number.

     David

On 11.10.21 23:42, David von Oheimb wrote:
> So in the end the whole IssuingDistributionPoint
> structure determines the scope.
>
>    David

On 11.10.21 21:45, Russ Housley wrote:
> Lijun:
>
> Yes, I agree.  That us the reason for crldpn in the syntax that I 
> suggested.
>
> Russ
>
>> On Oct 11, 2021, at 3:26 PM, Lijun Liao <[e-mail]> wrote:
>>
>> The URL specified in the extension CRL DP, should be able to identify 
>> the scope.
>>
>>
>> Russ Housley <[e-mail]> schrieb am Mo., 11. Okt. 2021, 20:11:
>>
>>     Hendrik:
>>
>>     As the introduction to Section 5 od RFC 5280 says, the scope can
>>     be based on "arbitrary local information".  Consider the example
>>     that I gave in my earlier response, where a CA uses multiple CRL
>>     distribution points.  One distribution point could be associated
>>     with NIST employees located in Boulder and a separate
>>     distribution point could be for NIST employees in Gaithersburg.
>>     There are certainly other ways to do this, including indirect
>>     CRLs, but this is one straightforward approach.
>>
>>     Russ
>>
>>>     On Oct 11, 2021, at 12:20 PM, Brockhaus, Hendrik
>>>     <[e-mail]> wrote:
>>>
>>>     Russ
>>>     The introduction to Section 5 gives some examples on different
>>>     scopes.
>>>     I du understand how to express theses scopes by using the flags
>>>     David mentioned.
>>>
>>>       * "all certificates issued by CA X"
>>>       * "all CA certificates issued by CA X"
>>>       * "all certificates issued by CA X that have been revoked for
>>>         reasons of key compromise and CA compromise",
>>>
>>>     But I have issues to understand how "all certificates issued to
>>>     the NIST employees located in Boulder" would be expressed.
>>>     Can you give an example?
>>>     Hendrik
>>>     *Von:*Russ Housley <[e-mail]>
>>>     *Gesendet:*Montag, 11. Oktober 2021 17:26
>>>     *An:*David von Oheimb <[e-mail]>
>>>     *Cc:*Lijun Liao <[e-mail]>;[e-mail];
>>>     Brockhaus, Hendrik (T RDA CST SEA-DE)
>>>     <[e-mail]>; John Gray <[e-mail]>
>>>     *Betreff:*Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a
>>>     current CRL
>>>     David:
>>>     These flags are clearly part of the scope. The use of CRL
>>>     distribution points in certificates can be used to divide the
>>>     population of certificates across many different CRLs.
>>>     Russ
>>>
>>>
>>>         On Oct 11, 2021, at 11:16 AM, David von Oheimb
>>>         <[e-mail]> wrote:
>>>         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
>>>         tohttps://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3
>>>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.3&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504801460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vQVV1IHUgSbjezDqvu%2F01JXhEGZ6Zpnarlmjs3z%2Famg%3D&reserved=0>
>>>         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
>>>         tohttps://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5
>>>         <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280%23section-5.2.5&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504811454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TfKtJ1iJ1vgi3rDWO9iUC3dr7pyzCpliVbHFEmuFPds%3D&reserved=0>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]>
>>>             <mailto:[e-mail]>
>>>             *Gesendet:*Samstag, 9. Oktober 2021 21:07
>>>             *An:*Lijun Liao<[e-mail]>
>>>             <mailto:[e-mail]>
>>>             *Cc:*Brockhaus, Hendrik (T RDA CST
>>>             SEA-DE)<[e-mail]>
>>>             <mailto:[e-mail]>;[e-mail];
>>>             von Oheimb, David (T RDA CST
>>>             SEA-DE)<[e-mail]>
>>>             <mailto:[e-mail]>; John
>>>             Gray<[e-mail]> <mailto:[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
>>>