Depends on which standard - X.509 or PKIX (from IETF) you want to follow. We made this fix too (because it didn't adversely affect our PKIX users). PKIX requires the CRL to be v2 or higher if you include extensions, while X509 only requires the CRL to be v2 or higher if you have critical extenions. I believe [so take this with a pound of salt :-)], that a "real" ASN.1 parser should be able to safely parse over extensions placed anywhere in an ASN.1 structure without barfing (which SSLeay can't do). So technically, if you create a CRL with extensions between thisUpdate and nextUpdate, the real parser can deal with that and verify the signature on it. Regards, Ambarish > -----Original Message----- > From: Brien Wheeler [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 20, 1999 3:34 PM > To: [EMAIL PROTECTED] > Subject: Bug in parsing CRLs from RSA Keon > > > Folks, > > In using an older version of SSLeay in our product, we have > run across the following situation which I believe to be a bug > in parsing of CRL_INFO structures. Essentially, the 1997 X.509 > standard states that the optional version number in a CRL_INFO is > present only if a critical extension is present and shall be absent > if no critical extensions are present. > > The RSA Keon certificate server creates CRLs that have an > Authority Key Identifier (always non-critical) extension in them, > and no version number (following the standard's mandated handling). > The version of SSLeay we're using (and OpenSSL 0.9.4) both fail > to parse these correctly because they only parse extensions if > the version number is present and greater than or equal to one. > > A proposed diff to address this is appended. > > Thanks, > Brien Wheeler > Director of Engineering > Authentica, Inc. > > -------- > *** openssl-0.9.4/crypto/asn1/x_crl.c.orig Wed Jun 2 13:14:44 1999 > --- openssl-0.9.4/crypto/asn1/x_crl.c Mon Dec 20 18:21:49 1999 > *************** > *** 190,209 **** > } > } > > ! if (ver >= 1) > { > ! if (ret->extensions != NULL) > ! { > ! while (sk_X509_EXTENSION_num(ret->extensions)) > ! X509_EXTENSION_free( > ! sk_X509_EXTENSION_pop(ret->extensions)); > ! } > ! > ! > M_ASN1_D2I_get_EXP_set_opt_type(X509_EXTENSION,ret->extensions, > ! d2i_X509_EXTENSION, > ! X509_EXTENSION_free,0, > ! V_ASN1_SEQUENCE); > } > > > M_ASN1_D2I_Finish(a,X509_CRL_INFO_free,ASN1_F_D2I_X509_CRL_INFO); > } > --- 190,214 ---- > } > } > > ! /* > ! * Always look for extensions. Previous code only looked if the > ! * version number was present and greater than or equal to one. > ! * However, the 1997 X.509 standard says that the version number > ! * shall be absent if no critical extensions exist. It is legal > ! * to have non-critical extensions and no version number, which > ! * the previous code failed to parse correctly. > ! */ > ! if (ret->extensions != NULL) > { > ! while (sk_X509_EXTENSION_num(ret->extensions)) > ! X509_EXTENSION_free( > ! sk_X509_EXTENSION_pop(ret->extensions)); > } > + > + M_ASN1_D2I_get_EXP_set_opt_type(X509_EXTENSION,ret->extensions, > + d2i_X509_EXTENSION, > + X509_EXTENSION_free,0, > + V_ASN1_SEQUENCE); > > > M_ASN1_D2I_Finish(a,X509_CRL_INFO_free,ASN1_F_D2I_X509_CRL_INFO); > } > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] >
i don't know why the rfc says what it says. we, the x.509 standard guys, wrote the stuff in the standard to allow maximum interoperability. under the rules of extensibility, one is supposed to ignore fields that one does not understand. let's suppose the verifying entity, x, that is checking the crl only understands version 1 (the version field was introduced by defect resolution and is to be supported by non-v2 implementations). let's supposed that entity y is responsible for constructing a crl that can be consumed by the largest number of verifiers possible. if y constructs a crl that has extensions that are all non-critical, then y can either: 1) signal that the crl is version 2; or 2) signal, or don't specify, the version number as version 1. if the first approach is taken, the relying party x will see that the crl is a higher version than x can accept and will go no farther. if the second approach is taken, x will ignore all of the extensions under the rules of extensibility and can still use the crl. since the generator of the crl, y, had not made any of the extensions critical, this is acceptable what we don't want is to have some implementation that knows nothing about this stuff ignore critical extensions. the only way to ensure that the verifier, e.g. x, won't ignore everything, including critical extensions, is to have x check the version number. if the version number is greater than 1, an old style verifier will not apply the rules of extensibility, ignore everything (including critical), and accept the crl. that is, it recognizes the version number field and it knows that it doesn't support that version. maybe the ietf group didn't care about the existence of old version verifiers (i.e. all users of interest conform to the pkix profile). what i can say is that the text in the standard is not an error. its phrasing was discussed for some time. unfortunately, as in many places in the standard, there is no explanation of why it states that. hoyt Srinivas Pandrangi <[EMAIL PROTECTED]> on 03/18/99 03:56:58 PM To: Ambarish Malpani <[EMAIL PROTECTED]> cc: Martin Lindstr�m <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Hoyt Kesterson/US/BULL) Subject: Re: CRL version field confusion Ambarish, X.509 does seem to say that version should be v1(0) if non-critical crlExtensions are present. It suggests that only crlEntryExtensions (in revokedCertificates), and "critical" crlExtensions imply a version of v2. This is in contrast to PKIX which says that the presence of any extension implies v2. --Srinivas Ambarish Malpani wrote: > Actually it isn't an ambiguity. The default value for the version > in CRLs, is v1 (i.e. 0). So if you are encoding a version 1 > CRL (ie. one with no extensions), you don't encode the version > number. > > Hope this helps, > Regards, > Ambarish > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf > Of Martin Lindstr�m > Sent: Thursday, March 18, 1999 12:48 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: CRL version field confusion > > I think I've found an ambiguity(?) between rfc2459 and the X.509 > in the way CRL version fields should be treated. > > X.509 says: "If any extensions included in a CertificateList are > defined as critical, the version element of the CertificateList > shall be present. If no extensions defined as critical are included, > the version element shall be absent" > > RFC2459 on the other hand says: "When extensions are used, as required > by this profile, this field MUST be present and MUST specify version 2" > > Depending on which definition I use to encode a CRL having no critical > extensions I get different results. Is this correct? > > /Martin > > ______________________________________ > Entegrity Solutions > > Martin Lindstr�m > Senior Systems Engineer > > Finlandsgatan 60 > S-164 74 Kista, Sweden > Direct: +46-(0)8-477-7735 > Fax: +46-(0)8-477-7731 > Cell: +46-(0)70-483-0024 > ______________________________________ -- ------------------------------------------------------------------- Srinivas Pandrangi XETI Inc. [EMAIL PROTECTED] (650) 694 6804 -------------------------------------------------------------------
Here are the details from the X.509 side: This correction to X.509 is being made, as agreed at the April 1999 meeting, through defect report DR 220. The nature of the defect is described as: "The current text requires that, if no extensions defined as critical are included in a CRL, the version element be absent from that CRL. While this may be helpful in some environments where backward compatibility with version 1 CRLs, this should not be mandatory behaviour. An issuer should be able to mark its CRL as v2 regardless of whether or not critical extensions are present. Note that some profiles (e.g. PKIX) require that all CRLs be v2." The changes to the text are currently under ballot and contained in DTC 3 to the 97 X.509 text and read as follows: In Note 3, in the second sentence replace "shall be absent" with "may be absent". In Note 3, at the beginning of the 3rd sentence, replace "This may permit" with "If version is absent, this may permit" In Note 3, at the beginning of the 4th sentence, replace "An implementation that supports version 2 (or greater) CRLs may" with "An implementation that supports version 2 (or greater) CRLs, in the absence of version, may also" The ballot closes in early November and at this point we are not anticipating any problems with approval. If anyone wants to see the documents themselves (defect report and DTC) here are links to them: ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509/DR_ 220 ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend a/X.509/8-DTC3(3rd).doc Sharon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 25, 1999 9:27 AM To: Hans Nilsson Cc: [EMAIL PROTECTED] Subject: Re: CRL version number discrepancy actually we have had this debate. the text is correct in 509 but it was considered an unnecessary complication in the pkix profile. the 509 text was to broaden the amount of interworking between different versions. i understood the pkix position to be that with minimal deployment of earlier versions, the 509 text didn't buy anything (other that possible confusion) i (and the x500 group) considered the text still useful but decided to make it optional. the "shall" will be changed to a "may". this will allow a profile to broaden interaction if necessary. whatever pkix decides to do, there will be no conflict with the standard. hoyt Hans Nilsson <[EMAIL PROTECTED]> on 08/24/99 11:34:06 PM To: [EMAIL PROTECTED] cc: (bcc: Hoyt Kesterson/US/BULL) Subject: CRL version number discrepancy There is a discrepancy between X.509 and RFC 2459. X.509 states: If any extensions included in a CertificateList are defined as critical, the version element of the CertificateList shall be present. If no extensions defined as critical are included, the version element shall be absent. This may permit a implementation that only supports version 1 CRLs to still use the CRL if in its examination of the revokedCertificates sequence in the CRL, it does not encounter an extension. An implementation that supports version 2 (or greater) CRLs may be able to optimize its processing if it can determine early in processing that no critical extensions are present in the CRL. RFC 2459 states that: Conforming CAs that issue CRLs MUST issue version 2 CRLs, and, later, When extensions are used, as required by this profile, this field MUST be present and MUST specify version 2 (the integer value is 1. The question is now: When we issue CRLS with non-crictical extensions, should the version number be omitted (according to X.509) or present and set to 2 (according to RFC 2459? Until further notice, we regard X.509 as having precedence over RFC 2459. Is this correct? Regards Hans Nilsson
actually we have had this debate. the text is correct in 509 but it was considered an unnecessary complication in the pkix profile. the 509 text was to broaden the amount of interworking between different versions. i understood the pkix position to be that with minimal deployment of earlier versions, the 509 text didn't buy anything (other that possible confusion) i (and the x500 group) considered the text still useful but decided to make it optional. the "shall" will be changed to a "may". this will allow a profile to broaden interaction if necessary. whatever pkix decides to do, there will be no conflict with the standard. hoyt Hans Nilsson <[EMAIL PROTECTED]> on 08/24/99 11:34:06 PM To: [EMAIL PROTECTED] cc: (bcc: Hoyt Kesterson/US/BULL) Subject: CRL version number discrepancy There is a discrepancy between X.509 and RFC 2459. X.509 states: If any extensions included in a CertificateList are defined as critical, the version element of the CertificateList shall be present. If no extensions defined as critical are included, the version element shall be absent. This may permit a implementation that only supports version 1 CRLs to still use the CRL if in its examination of the revokedCertificates sequence in the CRL, it does not encounter an extension. An implementation that supports version 2 (or greater) CRLs may be able to optimize its processing if it can determine early in processing that no critical extensions are present in the CRL. RFC 2459 states that: Conforming CAs that issue CRLs MUST issue version 2 CRLs, and, later, When extensions are used, as required by this profile, this field MUST be present and MUST specify version 2 (the integer value is 1. The question is now: When we issue CRLS with non-crictical extensions, should the version number be omitted (according to X.509) or present and set to 2 (according to RFC 2459? Until further notice, we regard X.509 as having precedence over RFC 2459. Is this correct? Regards Hans Nilsson
