IETF Logo Mail Archive

[pkix] Ambiguity in 5280 Regarding EKU Processing During Certification Path Processing

"Santosh Chokhani" <SChokhani@cygnacom.com> Wed, 28 October 2009 15:48 UTC

Return-Path: <schokhani@cygnacom.com>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3FA3A6975 for <pkix@core3.amsl.com>; Wed, 28 Oct 2009 08:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTYd7f4otcCR for <pkix@core3.amsl.com>; Wed, 28 Oct 2009 08:48:00 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 042193A68ED for <pkix@ietf.org>; Wed, 28 Oct 2009 08:47:59 -0700 (PDT)
Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9SFmDpk072175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Wed, 28 Oct 2009 08:48:14 -0700 (MST) (envelope-from schokhani@cygnacom.com)
Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id fb768ea4.2620066736.24510.00-035.p03c11o141.symantecmail.net (envelope-from <schokhani@cygnacom.com>); Wed, 28 Oct 2009 09:48:15 -0600 (MDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 28 Oct 2009 11:48:09 -0400
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48D91762@scygexch1.cygnacom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Ambiguity in 5280 Regarding EKU Processing During Certification Path Processing
thread-index: AcpX5gw51vxGR8WsRdiZk4UlRCP/QA==
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: ietf-pkix@imc.org
X-Spam: [F=0.2000000000; S=0.200(2009101401)]
X-MAIL-FROM: <schokhani@cygnacom.com>
X-SOURCE-IP: [65.242.48.5]
Subject: [pkix] Ambiguity in 5280 Regarding EKU Processing During Certification Path Processing
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 28 Oct 2009 15:48:01 -0000

I am having some trouble deciding on how to interpret 5280 when extended
key usage appears in the CA certificates.

This is not a hypothetical scenario.  It has actually happened.  That
said, I am not sure how the vendor product actually behave (i.e., I have
not come across convincing test results).

I have come across the following interpretations from myself (who does
not cut code) and from folks who write PK enablement code as open source
or who are commercial vendors.

1. My interpretation: EKU in the trust anchor and in intermediate
certificates in certification paths should be ignored.

2. Open Source Developer Viewpoint: The path validation engine is EKU
unaware and thus ignores non-critical EKU and rejects the path when EKU
is marked critical.

3. Commercial Vendor Viewpoint: If EKU is present in the certificates in
the path, it needs to be valid for the purpose end certificate will be
used for.

4. Yet Another Interpretation: If EKU is present in the certificates in
the path, it must be valid for the purpose (albeit, there is no
particular defined EKU purpose for certificate or CRL signing and hence
the certificate will be rejected unless anyExtendedKeyUsageKeyPurposeId
is present).

Some of the above can have variations if anyExtendedKeyUsageKeyPurposeId
is present.

In short, different people have different interpretation of 5280 in this
regard and will give different path validation results.

Some clarity may be required.

My thinking is that RFC 5280 should do the following:

1. Requiring CA certificates not contain any EKU.  (My reading of 2560
is that a CA does not need OCSPSigning EKU for signing OCSP responses
and this constraint requires CA to use another key for time stamp
signing which is a good security practice).

2. Requiring compliant consumers to recognize and ignore EKU in
intermediate certificates in the certification path.

An alternative is of-course that all of the above are valid
interpretations.

Santosh Chokhani
CygnaCom Solutions

v2.23.0 | Report a Bug | By Email