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

So in the end the whole   IssuingDistributionPoint
structure determines the scope.

  David

11 Oct 2021 21:46:09 Russ Housley <housley@vigilsec.com>:

> 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 <lijun.liao@gmail.com> wrote:
> 
> The URL specified in the extension CRL DP, should be able to identify the scope.
> 
> 
> Russ Housley <housley@vigilsec.com> 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 <hendrik.brockhaus@siemens.com> 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 <housley@vigilsec.com> 
>> *Gesendet:* Montag, 11. Oktober 2021 17:26
>> *An:* David von Oheimb <nl0@von-Oheimb.de>
>> *Cc:* Lijun Liao <lijun.liao@gmail.com>; spasm@ietf.org; Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com>; John Gray <John.Gray@entrust.com>
>> *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 <nl0@von-Oheimb.de> 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 to https://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 to https://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:
>> …
>> _______________________________________________
>> Spasm mailing list
>> 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%7C730a6cf99cfe45f6b1e508d98ccb6733%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637695627504821448%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Gb6HS9iVC5ymX804Hud7r1qIUOUWu4lzIx7CxUitVJI%3D&reserved=0]
>>  
>> _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm
>> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm