RE: X.509 Extensions Enhancements
"Carlin Covey" <ccovey@cylink.com> Tue, 12 June 2001 18:31 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 OAA21951 for <pkix-archive@odin.ietf.org>; Tue, 12 Jun 2001 14:31:15 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CHhkI09601 for ietf-pkix-bks; Tue, 12 Jun 2001 10:43:46 -0700 (PDT)
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CHhkJ09597 for <ietf-pkix@imc.org>; Tue, 12 Jun 2001 10:43:46 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M4H20SLA; Tue, 12 Jun 2001 10:43:08 -0700
From: Carlin Covey <ccovey@cylink.com>
To: "Housley, Russ" <rhousley@rsasecurity.com>, ietf-pkix@imc.org
Subject: RE: X.509 Extensions Enhancements
Date: Tue, 12 Jun 2001 10:43:50 -0700
Message-ID: <KHEDLMGGCCGHDAAKNAFOCEKDCAAA.ccovey@cylink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.0.1.4.2.20010612120440.02009ef8@exna07.securitydynamics.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: 7bit
Russ, Thank you for pointing this out. I had seen the flags in X.509 but didn't realize that they had not been incorporated into "son". But I have a comment concerning the DER encoding of the named bit string. Some people interpret X.680/690 as requiring that the DER encoding omit trailing zeros from such a named bit string. I (with some concurrence from the X.509 folks) believe that this is an error. X.680/690 say that trailing UNUSED bits are to be omitted. Bits (7) and (8) WERE unused, and certificates issued in ignorance of the newly defined bits should omit them. But certificates issued in cognizance of the newly defined bits should include these bits as either 1 or 0, as appropriate. If relying party applications assume that omitted trailing bits have a value of 0, these applications cannot discern between a CA that knows that the privilege is still good and that the Attribute Authority is not compromised, from a CA who hasn't a clue about either. The newly added bits have three values: true, false, and omitted. Omitted indicates that the CA has no opinion about the value of these flags (probably because the certificate was issued or the CA software was written prior to these bits being defined). Regards, Carlin ____________________________ - Carlin Covey Cylink Corporation -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of Housley, Russ Sent: Tuesday, June 12, 2001 9:18 AM To: ietf-pkix@imc.org Subject: X.509 Extensions Enhancements I have just been made aware that the most recent X.509 includes two additional reason codes. This impacts the reasons in the CRL Distribution Points certificate extension and the onlySomeReasons in the Issuing Distribution Point CRL extension. Both of these fields use the ReasonFlags type. It also impacts the Reason Code CRL entry extension, which uses the CRLReason type. I have provided the new definitions below. ReasonFlags ::= BIT STRING { unused (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), privilegeWithdrawn (7), aACompromise (8) } CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), aaCompromise (10) } The Issuing Distribution Point CRL extension has also been enhanced to include a boolean that indicates whether the CRL contains only entries associated with attribute certificates. The new definition is: IssuingDistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE, onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } The original OIDs are still being used with these "enhanced" definitions, therefore I will be adding them to son-of-rfc2459. Russ
- X.509 Extensions Enhancements Housley, Russ
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Charles W. Gardiner
- Re: X.509 Extensions Enhancements Dean Povey
- Re: X.509 Extensions Enhancements Hoyt L. Kesterson II
- RE: X.509 Extensions Enhancements Hoyt L. Kesterson II
- Re: X.509 Extensions Enhancements Bodo Moeller
- RE: X.509 Extensions Enhancements David A. Cooper
- RE: X.509 Extensions Enhancements Hoyt L. Kesterson II
- Re: X.509 Extensions Enhancements Bodo Moeller
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Tom Gindin
- Re: X.509 Extensions Enhancements Bodo Moeller
- Re: X.509 Extensions Enhancements Phil Griffin
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Tom Gindin
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Carlin Covey
- Re: X.509 Extensions Enhancements Phil Griffin
- RE: X.509 Extensions Enhancements Carlin Covey
- Re: X.509 Extensions Enhancements David P. Kemp
- Re: X.509 Extensions Enhancements Phil Griffin
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements David A. Cooper