RE: X.509 Extensions Enhancements

["Charles W. Gardiner" <[e-mail]>]

At 10:43 AM 6/12/2001 -0700, Carlin Covey wrote:

>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.

     Paragraph 11.2.2 of X.690 states that, for named bit strings 
(paragra[h 19.7 of X.680) all trailing zero bits must be removed before 
encoding.  Paragraph 11.2.1, which refers to bit strings of either kind, 
speaks of unused bits in the final octet being zero.  I believe the 
specific case for named bit strings trumps the general case.

Charlie Gardiner

>  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: [e-mail]
>[mailto:[e-mail]]On Behalf Of Housley, Russ
>Sent: Tuesday, June 12, 2001 9:18 AM
>To: [e-mail]
>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