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