Subject: [pkix] Indirect CRLs

From: "Erik Andersen" <[email-masked]>
Date: Mon, 16 Nov 2015 10:47:56 +0100

I have a question related to indirect CRLs. RFC 5280 in Section 5:

If the scope of the CRL includes one or more certificates issued by

an entity other than the CRL issuer, then it is an indirect CRL.

If a CA has delegated CRL issuing to another entity, but this entity only
issues revocation status for certificates issued by that CA, is the CRL then
an indirect CRL?

Erik

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 Nov 2015 11:57:15 -0500

Yes.  That is an indirect CRL.

Note that the CA needs to assert appropriate cRLIssuer in the
DistributionPoint field of CRL DP extension of each certificate the CA
issues.

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Monday, November 16, 2015 4:48 AM
To: PKIX <[email-masked]>
Cc: Directory list <[email-masked]>
Subject: [x500standard] Indirect CRLs

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 17 Nov 2015 09:14:01 +0100

Hi Santosh,

Thanks a lot for your answer.

My first impression reading the text was that an indirect CRL is one that
potentially holds revocation information from multiple CAs. Others may have
the same impression. I will check X.509 to see  if it  clear enough on this
point.

Kind regards,

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Santosh Chokhani
Sendt: 16 November 2015 17:57
Til: [email-masked]; 'PKIX' <[email-masked]>
Emne: Re: [pkix] [x500standard] Indirect CRLs

From: [email-masked]
<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Monday, November 16, 2015 4:48 AM
To: PKIX <[email-masked] <mailto:[email-masked]> >
Cc: Directory list <[email-masked]
<mailto:[email-masked]> >
Subject: [x500standard] Indirect CRLs

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 17 Nov 2015 09:36:55 +0100

Hi Santosh,

In continuation, I checked the X.509 definition for  indirect CRL :

3.5.36   indirect CRL (iCRL): A revocation list that contains at least
revocation information about certificates issued by authorities other than
that which issued this CRL.

This could be a little confusing.

As I understand from your answer, if I as CA delegate the CRL issuing to a
closely related function or even if I locally generate a new PKC with
another subject name  just for signing CRLs, it is still an indirect CRL.

Regards,

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Erik Andersen
Sendt: 17 November 2015 09:14
Til: 'Santosh Chokhani' <[email-masked]>;
[email-masked]; 'PKIX' <[email-masked]>
Emne: Re: [pkix] [x500standard] Indirect CRLs

Hi Santosh,

Kind regards,

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Santosh Chokhani
Sendt: 16 November 2015 17:57
Til: [email-masked] <mailto:[email-masked]> ; 'PKIX'
<[email-masked] <mailto:[email-masked]> >
Emne: Re: [pkix] [x500standard] Indirect CRLs

Erik

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 Nov 2015 09:39:10 -0500

Erik,

Yes it is.

There is no other mechanism defined in X.509 to delegate CRL issuance.  

From: Erik Andersen [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 3:37 AM
To: 'Santosh Chokhani' <[email-masked]>;
[email-masked]; 'PKIX' <[email-masked]>
Subject: SV: [pkix] [x500standard] Indirect CRLs

Hi Santosh,

Regards,

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Erik Andersen
Sendt: 17 November 2015 09:14
Til: 'Santosh Chokhani' <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; 'PKIX' <[email-masked]
<mailto:[email-masked]> >
Emne: Re: [pkix] [x500standard] Indirect CRLs

Hi Santosh,

Kind regards,

Erik

Erik

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 17 Nov 2015 19:45:03 +0000

The confusion is worse than that:

    authority: An entity, responsible for the issuance of certificates. Two types are defined
    in this Recommendation | International Standard; a certification authority which issues public-key
    certificates and an attribute authority which issues attribute certificates.

    indirect CRL (iCRL): A revocation list that contains at least revocation information about
    certificates issued by authorities other than that which issued this CRL.

According to these definitions, an iCRL is issued by an authority, which can be only an issuer of PKCs or an issuer of ACs.  That's not just confusing, it's wrong.

But assuming that a third type of authority is added to the definition, there is still the question of the relationship between entities and identifiers.  If one entity has more than one identifier (e.g., a CA cert containing one subject name and an EE cert with a different subject name referenced in a CRL DP), the relying party has no way of determining that they are the same "entity".  A heuristic definition of entity would say that two distinct identifiers refer to the same entity only if the identifiers are bound together, e.g., by appearing in the Subject Name and Subject Alt Name of the same certificate.

So to answer your question, if you locally generate a new PKC with another subject name just for signing CRLs, then you have created a new authority / entity that is distinct from the CA.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Tuesday, November 17, 2015 9:39 AM
To: 'Erik Andersen'; [email-masked]; 'PKIX'
Subject: [x500standard] Re: [pkix] Indirect CRLs

Erik,

Yes it is.

From: Erik Andersen [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 3:37 AM
To: 'Santosh Chokhani' <[email-masked]>; [email-masked]; 'PKIX' <[email-masked]>
Subject: SV: [pkix] [x500standard] Indirect CRLs

Hi Santosh,

3.5.36   indirect CRL (iCRL): A revocation list that contains at least revocation information about certificates issued by authorities other than that which issued this CRL.

As I understand from your answer, if I as CA delegate the CRL issuing to a closely related function or even if I locally generate a new PKC with another subject name  just for signing CRLs, it is still an indirect CRL.

Regards,

Erik

Fra: pkix [mailto:[email-masked]] På vegne af Erik Andersen
Sendt: 17 November 2015 09:14
Til: 'Santosh Chokhani' <[email-masked]>; [email-masked]; 'PKIX' <[email-masked]>
Emne: Re: [pkix] [x500standard] Indirect CRLs

Hi Santosh,

My first impression reading the text was that an indirect CRL is one that potentially holds revocation information from multiple CAs. Others may have the same impression. I will check X.509 to see  if it  clear enough on this point.

Kind regards,

Erik

Note that the CA needs to assert appropriate cRLIssuer in the DistributionPoint field of CRL DP extension of each certificate the CA issues.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Monday, November 16, 2015 4:48 AM
To: PKIX <[email-masked]>
Cc: Directory list <[email-masked]>
Subject: [x500standard] Indirect CRLs

If a CA has delegated CRL issuing to another entity, but this entity only issues revocation status for certificates issued by that CA, is the CRL then an indirect CRL?

Erik

---

From: "Erik Andersen" <[email-masked]>
Date: Wed, 18 Nov 2015 10:33:02 +0100

Hi David,

Thanks for your input. 

You are touching on something about entities. The entity concept is somewhat
confusing. I have made a suggestion in the form of a defect report I have
not so far published. I am not sure how it will be received. I have not
included the issue on entity naming as you mentioned. The proposed defect
report may be found on http://www.x500standard.com/uploads/Ig/DR_414.pdf.  I
will be happy for any comments and/or proposed enhancement.

Kind regards,

Erik
-----Oprindelig meddelelse-----
Fra: Kemp, David P. [mailto:[email-masked]] 
Sendt: 17 November 2015 20:45
Til: [email-masked]; 'Erik Andersen' <[email-masked]>; 'PKIX'
<[email-masked]>
Emne: RE: [x500standard] Re: [pkix] Indirect CRLs

    authority: An entity, responsible for the issuance of certificates. Two
types are defined
    in this Recommendation | International Standard; a certification
authority which issues public-key
    certificates and an attribute authority which issues attribute
certificates.

    indirect CRL (iCRL): A revocation list that contains at least revocation
information about
    certificates issued by authorities other than that which issued this
CRL.

According to these definitions, an iCRL is issued by an authority, which can
be only an issuer of PKCs or an issuer of ACs.  That's not just confusing,
it's wrong.

But assuming that a third type of authority is added to the definition,
there is still the question of the relationship between entities and
identifiers.  If one entity has more than one identifier (e.g., a CA cert
containing one subject name and an EE cert with a different subject name
referenced in a CRL DP), the relying party has no way of determining that
they are the same "entity".  A heuristic definition of entity would say that
two distinct identifiers refer to the same entity only if the identifiers
are bound together, e.g., by appearing in the Subject Name and Subject Alt
Name of the same certificate.

So to answer your question, if you locally generate a new PKC with another
subject name just for signing CRLs, then you have created a new authority /
entity that is distinct from the CA.

-----Original Message-----
[mailto:[email-masked]] On Behalf Of Santosh Chokhani

Erik,

Yes it is.

Hi Santosh,

Regards,

Erik

Hi Santosh,

Kind regards,

Erik

Erik

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Nov 2015 15:54:11 +0100 (CET)

> DistributionPoint field of CRL DP extension of each certificate the CA

Huh?  The latter comment has exactly nothing to do with indirect CRLs.

-Martin

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 19 Nov 2015 11:26:34 -0500

Without doing the latter, the relying party will not be able to use the
indirect CRL to verify the revocation status of the certificate in the scope
of the indirect CRL.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, November 19, 2015 9:54 AM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

-Martin

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 19 Nov 2015 17:51:35 +0100

Within X.509 there is not even a small paragraph introducing indirect CRLs
where such information could be introduced. Besides the brief definition,
iCRLs are mentioned the first time within the CRL scope extension (which is
deprecated).

Erik

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, November 19, 2015 9:54 AM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

-Martin

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Nov 2015 19:03:04 +0100 (CET)

> indirect CRL to verify the revocation status of the certificate in the scope

One of the nursing problems with indirectCRLs is, that the fact that
a CRL is indirect can _only_ be conveyed through the OPTIONAL(!!)
critical CRL Extension "IssuingDistributionPoint" -- which immediately
makes such CRLs incomprehensible to perfectly PKIX-compliant,
minimal-requirement RPs in addition to OCSP responders that feed
on CRLs (such as local OCSP responders).

But other than that, if the indirectCRL is a "Full and complete" CRL,
i.e. one where the IssuingDistributionPoint CRL extension is populated
only with the "indirectCRL = TRUE" Boolean and _nothing_else_,
then the CRL and certificate verification should simply succeed
as long as the relying party is able to obtain (out-of-band) the
necessary CRL signer certificate and verify this CRL signer cert
under the same trust anchor as the certificate.

-Martin

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 19 Nov 2015 13:51:34 -0500

Erik,

Look at Section 8.6.2.1 of X.509 and I quote the following: "The cRLIssuer
component identifies the authority that issues and signs the CRL. If this
component is absent, the CRL
issuer name defaults to the certificate issuer name."

Also see Section C.5.1.4 of X.509

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Thursday, November 19, 2015 11:52 AM
To: [email-masked]; 'PKIX' <[email-masked]>
Subject: [x500standard] SV: [pkix] Indirect CRLs

Erik

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, November 19, 2015 9:54 AM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

-Martin

-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 19 Nov 2015 14:07:34 -0500

I do not want to digress to much afar from the point here. 

I am not a fan of indirect CRL.  You can see my 10-11 year old presentation
to PKIX or circa 2005-6 paper at NIST PKI research conference.  I advocate
against it.

That said, all I am trying to state is how to produce and consume this
beast.

Also see in-line.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, November 19, 2015 1:03 PM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

Santosh Chokhani wrote:
> Without doing the latter, the relying party will not be able to use 
> the indirect CRL to verify the revocation status of the certificate in 
> the scope of the indirect CRL.

One of the nursing problems with indirectCRLs is, that the fact that a CRL
is indirect can _only_ be conveyed through the OPTIONAL(!!) critical CRL
Extension "IssuingDistributionPoint" -- which immediately makes such CRLs
incomprehensible to perfectly PKIX-compliant, minimal-requirement RPs in
addition to OCSP responders that feed on CRLs (such as local OCSP
responders).
[Santosh] OCSP Responders generally use full CRL hopefully issued by the CA,

But other than that, if the indirectCRL is a "Full and complete" CRL, i.e.
one where the IssuingDistributionPoint CRL extension is populated only with
the "indirectCRL = TRUE" Boolean and _nothing_else_, then the CRL and
certificate verification should simply succeed as long as the relying party
is able to obtain (out-of-band) the necessary CRL signer certificate and
verify this CRL signer cert under the same trust anchor as the certificate.
[Santosh] In your scenario, the first entry in the revocation list will have
critical CRL entry extension identifying the certificate issuer.  And, all
of the certificate will have CRL DP with CRL Issuer listed.  That is how
X.509 is designed and intended.  Also see RFC 5280 Section 6.3.3 (b) (1).

-Martin

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 20 Nov 2015 11:59:31 +0100

Hi Santosh,

Try to imagine a guy that is completely new in PKI and pick-up X.509 or RFC
5280 to learn about it. Will he understand what an indirect CRL is by just
looking at some brief statements on an iCRL is.

8.5.2.2	CRL scope extension (deprecated) has the following statements:

–	simple CRLs that provide revocation information about certificates
issued by a single authority; 
–	indirect CRLs that provide revocation information about certificates
issued by multiple authorities;

It was a statement like this that made me wrongly to believe that it is only
an iCRL if there are certificate info from multiple authorities.

I also some comments on your other mail.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: [email-masked]
[mailto:[email-masked]] På vegne af Santosh Chokhani
Sendt: 19 November 2015 19:52
Til: [email-masked]; 'PKIX' <[email-masked]>
Emne: [x500standard] Re: SV: [pkix] Indirect CRLs

Erik,

Look at Section 8.6.2.1 of X.509 and I quote the following: "The cRLIssuer
component identifies the authority that issues and signs the CRL. If this
component is absent, the CRL issuer name defaults to the certificate issuer
name."

-----Original Message-----

Erik

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, November 19, 2015 9:54 AM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

-Martin

-----

-----

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 20 Nov 2015 10:43:39 -0500

Erik,

I am happy to help craft or review additional exposition if that helps.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Friday, November 20, 2015 6:00 AM
To: [email-masked]; 'PKIX' <[email-masked]>
Subject: [x500standard] SV: Re: SV: [pkix] Indirect CRLs

Hi Santosh,

Regards,

Erik

-----Oprindelig meddelelse-----

Erik,

-----Original Message-----

Erik

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, November 19, 2015 9:54 AM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

-Martin

-----

-----

-----

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 20 Nov 2015 17:33:46 +0100

Hi Santosh,

Thanks a lot. That would be very helpful. I am quite pressed for time. It is
the plan to have the next edition of X.509 ready at ITU-T  September next
year. This is necessary, as the smart grid security people need to reference
X.509 for their use of authorization and validation lists (whitelists). To
meet the schedule, I need to have the next PDAM out for ballot at the end of
this month. The same applies for a technical corrigendum covering all
identified defects.

Regards,

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Santosh Chokhani
Sendt: 20 November 2015 16:44
Til: [email-masked]; 'PKIX' <[email-masked]>
Emne: Re: [pkix] [x500standard] SV: Re: SV: Indirect CRLs

Erik,

-----Original Message-----

Hi Santosh,

Regards,

Erik

-----Oprindelig meddelelse-----

Erik,

-----Original Message-----

Erik

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, November 19, 2015 9:54 AM
To: Santosh Chokhani <[email-masked]>
Cc: [email-masked]; 'PKIX' <[email-masked]>
Subject: Re: [pkix] [x500standard] Indirect CRLs

-Martin

-----

-----

-----

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 16:36:14 +0000

> this month. The same applies for a technical corrigendum covering all

A suggestion: why not make that draft visible to folks here. I think
you'd get comments that would improve it.

S.

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 20 Nov 2015 18:05:12 +0100

Hi Stephen,

I will put the PDAM text and the drat technical corrigendum up on our web site (http://www.x500standard.com/) and provide exact links. Any comments and suggestions on the lists can then be converted to ballot comments to be considered at the ITU-T meeting March 2016. It is important to have maximum consensus.

Kind regards,

Erik

-----Oprindelig meddelelse-----
Fra: Stephen Farrell [mailto:[email-masked]] 
Sendt: 20 November 2015 17:36
Til: Erik Andersen <[email-masked]>; [email-masked]; 'PKIX' <[email-masked]>
Emne: Re: [pkix] [x500standard] SV: Re: SV: Indirect CRLs

On 20/11/15 16:33, Erik Andersen wrote:
> Hi Santosh,
> 
> Thanks a lot. That would be very helpful. I am quite pressed for time. 
> It is the plan to have the next edition of X.509 ready at ITU-T  
> September next year. This is necessary, as the smart grid security 
> people need to reference
> X.509 for their use of authorization and validation lists 
> (whitelists). To meet the schedule, I need to have the next PDAM out 
> for ballot at the end of this month. The same applies for a technical 
> corrigendum covering all identified defects.

A suggestion: why not make that draft visible to folks here. I think you'd get comments that would improve it.

S.

> 5280 to learn about it. Will he understand what an indirect CRL is by 
> just looking at some brief statements on an iCRL is.
> 
> It was a statement like this that made me wrongly to believe that it 
> is only an iCRL if there are certificate info from multiple authorities.
> 
> Look at Section 8.6.2.1 of X.509 and I quote the following: "The 
> cRLIssuer component identifies the authority that issues and signs the 
> CRL. If this component is absent, the CRL issuer name defaults to the 
> certificate issuer name."
> 
> Within X.509 there is not even a small paragraph introducing indirect 
> CRLs where such information could be introduced. Besides the brief 
> definition, iCRLs are mentioned the first time within the CRL scope 
> extension (which is deprecated).
> 
> Erik
>> DistributionPoint field of CRL DP extension of each certificate the 
>> CA issues.
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2015 17:07:05 +0000

On 20/11/15 17:05, Erik Andersen wrote:
> Hi Stephen,
> 
> I will put the PDAM text and the drat technical corrigendum up on our
> web site (http://www.x500standard.com/) and provide exact links. Any
> comments and suggestions on the lists can then be converted to ballot
> comments to be considered at the ITU-T meeting March 2016. It is
> important to have maximum consensus.

Great,
Thanks,
S.

> 
> Kind regards,
> 
> Erik
> 
> -----Oprindelig meddelelse----- Fra: Stephen Farrell
> [mailto:[email-masked]] Sendt: 20 November 2015 17:36 Til:
> Erik Andersen <[email-masked]>; [email-masked]; 'PKIX'
> <[email-masked]> Emne: Re: [pkix] [x500standard] SV: Re: SV: Indirect
> CRLs
> 
> 
> 
>> Thanks a lot. That would be very helpful. I am quite pressed for
>> time. It is the plan to have the next edition of X.509 ready at
>> ITU-T September next year. This is necessary, as the smart grid
>> security people need to reference X.509 for their use of
>> authorization and validation lists (whitelists). To meet the
>> schedule, I need to have the next PDAM out for ballot at the end of
>> this month. The same applies for a technical corrigendum covering
>> all identified defects.
> 
>> -----Oprindelig meddelelse----- Fra: pkix
>> [mailto:[email-masked]] På vegne af Santosh Chokhani Sendt:
>> 20 November 2015 16:44 Til: [email-masked]; 'PKIX'
>> <[email-masked]> Emne: Re: [pkix] [x500standard] SV: Re: SV:
>> Indirect CRLs
>> 
>> Erik,
>> 
>> -----Original Message----- From: [email-masked]
>>  [mailto:[email-masked]] On Behalf Of Erik
>> Andersen Sent: Friday, November 20, 2015 6:00 AM To:
>> [email-masked]; 'PKIX' <[email-masked]> Subject:
>> [x500standard] SV: Re: SV: [pkix] Indirect CRLs
>> 
>> Hi Santosh,
>> 
>> Try to imagine a guy that is completely new in PKI and pick-up
>> X.509 or RFC 5280 to learn about it. Will he understand what an
>> indirect CRL is by just looking at some brief statements on an iCRL
>> is.
>> 
>> –	simple CRLs that provide revocation information about
>> certificates issued by a single authority; –	indirect CRLs that
>> provide revocation information about certificates issued by
>> multiple authorities;
>> 
>> It was a statement like this that made me wrongly to believe that
>> it is only an iCRL if there are certificate info from multiple
>> authorities.
>> 
>> -----Oprindelig meddelelse----- Fra:
>> [email-masked] 
>> [mailto:[email-masked]] På vegne af Santosh 
>> Chokhani Sendt: 19 November 2015 19:52 Til:
>> [email-masked]; 'PKIX' <[email-masked]> Emne:
>> [x500standard] Re: SV: [pkix] Indirect CRLs
>> 
>> Erik,
>> 
>> cRLIssuer component identifies the authority that issues and signs
>> the CRL. If this component is absent, the CRL issuer name defaults
>> to the certificate issuer name."
>> 
>> -----Original Message----- From: [email-masked]
>>  [mailto:[email-masked]] On Behalf Of Erik
>> Andersen Sent: Thursday, November 19, 2015 11:52 AM To:
>> [email-masked]; 'PKIX' <[email-masked]> Subject:
>> [x500standard] SV: [pkix] Indirect CRLs
>> 
>> Within X.509 there is not even a small paragraph introducing
>> indirect CRLs where such information could be introduced. Besides
>> the brief definition, iCRLs are mentioned the first time within the
>> CRL scope extension (which is deprecated).
>> 
>> Erik -----Oprindelig meddelelse----- Fra: pkix
>> [mailto:[email-masked]] På vegne af Santosh Chokhani Sendt:
>> 19 November 2015 17:27 Til: [email-masked] Cc:
>> [email-masked]; 'PKIX' <[email-masked]> Emne: Re: [pkix]
>> [x500standard] Indirect CRLs
>> 
>>  the indirect CRL to verify the revocation status of the
>> certificate in the scope of the indirect CRL.
>> 
>> -----Original Message----- From: Martin Rex [mailto:[email-masked]] 
>> Sent: Thursday, November 19, 2015 9:54 AM To: Santosh Chokhani
>> <[email-masked]> Cc: [email-masked]; 'PKIX'
>> <[email-masked]> Subject: Re: [pkix] [x500standard] Indirect CRLs
>> 
>> Santosh Chokhani wrote:
>>> DistributionPoint field of CRL DP extension of each certificate
>>> the CA issues.
>> 
>> _______________________________________________ pkix mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>> 
>> ----- www.x500standard.com: The central source for information on
>> the X.500 Directory Standard.
>> 
>> 
>> ----- www.x500standard.com: The central source for information on
>> the X.500 Directory Standard.
>> 
>> ----- www.x500standard.com: The central source for information on
>> the X.500 Directory Standard.
>> 
>> 
>> _______________________________________________ pkix mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>> 
>> _______________________________________________ pkix mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>> 
> 
> _______________________________________________ pkix mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>