RE: RFC 3280 bug? - Special processing for self issued certificates
"Stefan Santesson" <stefans@microsoft.com> Mon, 30 August 2004 17:39 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11867 for <pkix-archive@lists.ietf.org>; Mon, 30 Aug 2004 13:39:59 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGg7GB060767; Mon, 30 Aug 2004 09:42:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UGg7A4060766; Mon, 30 Aug 2004 09:42:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UGg6Fa060757 for <ietf-pkix@imc.org>; Mon, 30 Aug 2004 09:42:06 -0700 (PDT) (envelope-from stefans@microsoft.com)
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 17:41:49 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC 3280 bug? - Special processing for self issued certificates
Date: Mon, 30 Aug 2004 17:41:31 +0100
Message-ID: <0C3042E92D8A714783E2C44AB9936E1D0132631D@EUR-MSG-03.europe.corp.microsoft.com>
Thread-Topic: RFC 3280 bug? - Special processing for self issued certificates
Thread-Index: AcSOrdBSGfy82zmTQMSptWq8vKtOpgAAUmUw
From: Stefan Santesson <stefans@microsoft.com>
To: Steve Hanna <shanna@funk.com>
Cc: Sharon Boeyen <sharon.boeyen@entrust.com>, ietf-pkix@imc.org
X-OriginalArrivalTime: 30 Aug 2004 16:41:49.0020 (UTC) FILETIME=[3EAE11C0:01C48EB0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UGg7Fa060761
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit
Thanks Steve, Yes, this is a valid technical argument. I suppose it is reasonable to accept a certificate as a key rollover cert despite name constraints violations in subjAltName while you wouldn't accept those violations if the same certificate was used as an EE cert to validate e.g. a new name constraints violating e-mail address of that CA. It seems harder however to transfer this logic to inhibit anyPolicy. Any ideas/arguments there? Stefan Santesson Microsoft Security Center of Excellence (SCOE) > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Steve Hanna > Sent: den 30 augusti 2004 17:07 > To: Stefan Santesson > Cc: Sharon Boeyen; ietf-pkix@imc.org > Subject: Re: RFC 3280 bug? - Special processing for self issued > certificates > > > Stefan, > > You wrote: > > For all valid paths to a self-issued certificate, the self-issued cert > > will be preceded by a valid intermediary CA certificate with a > > matching subject name. Lets call that the ICA cert. > > > > It seams reasonable to me that that IF ICA has a valid subject name > > then that name would be OK also for the rollover cert, regardless of > > whether it is used as an intermediary cert or validated as target > > cert. > > I will admit I had to check the archives on this one. > Your argument seemed compelling at first. But the email > below explains the problem. In a nutshell, the self-issued > certificate can contain a *subjectAltName* that is not > permitted by the name constraints and not contained in > the ICA cert. > > I hope that explains why this requirement is needed. > > Thanks, > > Steve > > -------- Original Message -------- > Date: Fri, 04 May 2001 12:44:34 -0400 > From: Steve Hanna <steve.hanna@sun.com> > To: PKIX List <ietf-pkix@imc.org> > Subject: Ignoring name constraints with self-issued certs > > Regretfully, I must raise another issue with son-of-2459. In section > 4.2.1.11 of draft-ietf-pkix-new-part1-06.txt, it says: > > Name constraints are not applied to certificates whose issuer and > subject are identical. (This could prevent CAs that use name > constraints from issuing self-signed certificates to implement key > rollover.) > > This statement is consistent with the validation algorithm in section > 6.1, which says: > > A certificate is termed self-issued if the DNs that appear in the > subject and issuer fields are identical and are not empty. In > general, the issuer and subject of the certificates that make up a > path are different for each certificate. However, a CA may issue a > certificate to itself to support key rollover or changes in > certificate policies. These self-issued certificates are not > counted when evaluating path length or name constraints. > > However, these statements (and the corresponding text in the validation > algorithm, steps (b) and (c) of section 6.1.3) are not consistent with > the text in X.509(2000), which says (in step g of section 10.5.1) "If > the certificate is not an intermediate self-issued certificate, check > that the subject name is within the name-space given by the value of > permitted-subtrees and is not within the name-space given by the value > of excluded-subtrees." > > Note the word *intermediate* in X.509(2000). If a self-issued > certificate is the last certificate in the path, the name constraints > check MUST be performed. Otherwise, a security hole is opened up. > Consider the following chain of 2 certificates: > > Certificate 1: > Issuer: o=trusty, c=us > Subject: o=shady, c=us > Basic Constraints: > cA=true > Name Constraints: > Permitted: > directoryName: o=shady, c=us > rfc822Name: .shady.com > > Certificate 2: > Issuer: o=shady, c=us > Subject: o=shady, c=us > SubjectAltNames: > rfc822Name: joe@partner.com > > If o=trusty, c=us is one of the trust anchors (and the certificate > signatures verify), this chain is valid according to son-of-2459. It is > not valid according to X.509(2000). I think you will agree that the > behavior described in X.509(2000) is correct. Otherwise, self-issued > certificates can be used to completely bypass the effects of name > constraints. > > Therefore, I suggest that section 4.2.1.11 of > draft-ietf-pkix-new-part1-06.txt be modified to say: > > Name constraints are not applied to certificates whose issuer and > subject are identical (unless the certificate is the final > certificate in the path). (This could prevent CAs that use name > constraints from issuing self-signed certificates to implement key > rollover.) > > We should also modify the last sentence of the paragraph in section 6.1 > that begins "A certificate is termed self-issued ..." (listed in full > above) to "These self-issued certificates are not counted when > evaluating path length. Name constraints are only applied to a > self-issued certificate if it is the final certificate in the path." > > I also suggest that the start of steps (b) and (c) in section 6.1.3 be > changed to read: > > (b) If certificate i is self-issued and it is not the final > certificate in the path, skip this step for certificate i. > Otherwise, verify that the subject name is within one of the > permitted_subtrees for X.500 distinguished names, and verify > that each of the alternative names in the subjectAltName > extension (critical or non-critical) is within one of the > permitted_subtrees for that name type. > > (c) If certificate i is self-issued and it is not the final > certificate in the path, skip this step for certificate i. > Otherwise, verify that the subject name is not within one of the > excluded_subtrees for X.500 distinguished names, and verify that > each of the alternative names in the subjectAltName extension > (critical or non-critical) is not within one of the > excluded_subtrees for that name type. > > Comments? > > Steve
- RFC 3280 bug? - Special processing for self issue… Stefan Santesson
- RE: RFC 3280 bug? - Special processing for self i… Stefan Santesson
- RE: RFC 3280 bug? - Special processing for self i… Stefan Santesson
- Re: RFC 3280 bug? - Special processing for self i… Steve Hanna
- RE: RFC 3280 bug? - Special processing for self i… Stefan Santesson
- RE: RFC 3280 bug? - Special processing for self i… Santosh Chokhani
- RE: RFC 3280 bug? - Special processing for self i… Stefan Santesson