Re: [pkix] [x500standard] Re: Indirect CRLs

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 17 November 2015 19:45 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05AE1A86F6 for <pkix@ietfa.amsl.com>; Tue, 17 Nov 2015 11:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.785
X-Spam-Level:
X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB35iig-awa8 for <pkix@ietfa.amsl.com>; Tue, 17 Nov 2015 11:45:12 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE631A86F2 for <pkix@ietf.org>; Tue, 17 Nov 2015 11:45:11 -0800 (PST)
Received: from Morgan.missi.ncsc.mil (pinto.missi.ncsc.mil [144.51.60.152]) by stingray.missi.ncsc.mil with ESMTP id tAHJj5u5020059; Tue, 17 Nov 2015 14:45:05 -0500 (EST)
Received: from MUSTANG.missi.ncsc.mil ([fe80::dd64:e457:4553:e1ff]) by PINTO.missi.ncsc.mil ([::1]) with mapi id 14.03.0248.002; Tue, 17 Nov 2015 14:45:04 -0500
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: "x500standard@freelists.org" <x500standard@freelists.org>, "'Erik Andersen'" <era@x500.eu>, "'PKIX'" <pkix@ietf.org>
Thread-Topic: [x500standard] Re: [pkix] Indirect CRLs
Thread-Index: AQHRIUW83WRt86mumkKNHLzmiYjzOZ6glnVg
Date: Tue, 17 Nov 2015 19:45:03 +0000
Message-ID: <5B1D7E570380A64989D4C069F7D14BC8DC3C6D9C@Mustang.missi.ncsc.mil>
References: <002701d12053$dee21d30$9ca65790$@x500.eu> <012001d1208f$d8cab330$8a601990$@gmail.com> <003b01d1210f$ead18240$c07486c0$@x500.eu> <004c01d12113$1dd26d00$59774700$@x500.eu> <072301d12145$b905cc40$2b1164c0$@gmail.com>
In-Reply-To: <072301d12145$b905cc40$2b1164c0$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [144.51.60.29]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/pVPVXdIMlxD0O9zxxkpm93uYxz0>
Subject: Re: [pkix] [x500standard] Re: Indirect CRLs
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 19:45:14 -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: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Santosh Chokhani
Sent: Tuesday, November 17, 2015 9:39 AM
To: 'Erik Andersen'; x500standard@freelists.org; 'PKIX'
Subject: [x500standard] Re: [pkix] Indirect CRLs

Erik,

 

Yes it is.

 

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

 

From: Erik Andersen [mailto:era@x500.eu] 
Sent: Tuesday, November 17, 2015 3:37 AM
To: 'Santosh Chokhani' <santosh.chokhani@gmail.com>om>; x500standard@freelists.org; 'PKIX' <pkix@ietf.org>
Subject: SV: [pkix] [x500standard] Indirect CRLs

 

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:pkix-bounces@ietf.org] På vegne af Erik Andersen
Sendt: 17 November 2015 09:14
Til: 'Santosh Chokhani' <santosh.chokhani@gmail.com>om>; x500standard@freelists.org; 'PKIX' <pkix@ietf.org>
Emne: Re: [pkix] [x500standard] Indirect CRLs

 

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:pkix-bounces@ietf.org] På vegne af Santosh Chokhani
Sendt: 16 November 2015 17:57
Til: x500standard@freelists.org; 'PKIX' <pkix@ietf.org>
Emne: Re: [pkix] [x500standard] Indirect CRLs

 

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: x500standard-bounce@freelists.org [mailto:x500standard-bounce@freelists.org] On Behalf Of Erik Andersen
Sent: Monday, November 16, 2015 4:48 AM
To: PKIX <pkix@ietf.org>
Cc: Directory list <x500standard@freelists.org>
Subject: [x500standard] Indirect CRLs

 

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