Subject: X.509: DR 274 "Attribute Certificate version" - keep [0] tag for issuer

From: "Manger, James H" <[email-masked]>
Date: Mon, 27 Nov 2000 17:08:40 +1100

RE: X.509 (2000) Defect Report 274 "Attribute Certificate version"

Keeping a [0] tag for the issuer v2 field would be beneficial.  It would
maintain compatibility of BER-encodings of AttributeCertificate values (2000
edition before and after DR).  Replace 11 c) in the DR with the following:

	c) In clause 12.1 replace the AttCertIssuer ASN.1 production with:
	AttCertIssuer ::= [0] SEQUENCE {
		issuerName GeneralNames OPTIONAL,
		baseCertificateID [0] IssuerSerial OPTIONAL,
		objectDigestInfo [1] ObjectDigestInfo OPTIONAL }

[If style dictates, the tag could be included in the issuer field in
AttributeCertificateInfo instead of in the AttCertIssuer type for the same
effect.]

This would also allow people (in their own implementations) to define a
composite type using CHOICE for the holder and issuer fields that works with
BER-encoded v1 and v2 values.

	AttributeCertificateInfo ::= SEQUENCE
		{
		version	AttCertVersion DEFAULT v1,
		holder	CHOICE {
			baseCertificateID	[0] IssuerSerial,
			subjectName		[1] GeneralNames,
			v2Form				SEQUENCE {
				baseCertificateID...
			}
		},
		issuer	CHOICE {
			v1Form	GeneralNames,
			v2Form	[0] SEQUENCE {
				issuerName...
			}
		},
		...
		}

P.S. typo in 11 b), should be "INTEGER", not "INTEBER"

> ----------
> From: 	Hoyt L. Kesterson II [mailto:[email-masked]] 
> Sent:	Monday, 27 November 2000 15:25
> To:	"X.509"
> Subject:	new defect reports against X.509
> 
> Three defects have been reported against X.509. we expect to generate
> Draft Technical Corrigenda within the next few weeks to correct these
> errors (as recommended in the defect reports). Those DTCs will be
> distributed for a three month ballot.
> 
> the defect reports can be found at
> 
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509an
> dRelated/DR_272.pdf
> 
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509an
> dRelated/DR_273.pdf
> 
> ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509an
> dRelated/DR_274.pdf
> 
> 
> --274
> 10. Nature of Defect:
> 
> There is an error in the asn.1 for AttributeCertificateInfo and the text
> below it that explains versioning.  Specifically a v1 certificate cannot
> be formed correctly with this ASN.1 because the holder syntax is not
> backward compatible. There is no requirement to carry v1 through to this 4
> th edition text and as such it is recommended that the 4 th edition
> require v2. The changes to the text in order to align with this are
> described below. The other option, which would also solve the problem, is
> to retain the option of v1 or v2 but this would require changing the
> syntax of holder to be a choice of v1 form or v2 form, similar to the way
> issuer is currently handled in the 4 th edition text. However, discussion
> among the defect resolution group to date agreed that it was unnecessary
> to carry over v1 to this edition and that the simplest solution is to
> require v2. Implementations may still support the v1 attribute certificate
> syntax as defined in the 3 rd edition text. Implementations wishing to
> support the v2 syntax would do so as defined in the 4 th edition text.
> 
> 11. Solution Proposed by the Source:
> 
> a) In clause 12.1 in the AttributeCertificateInfo ASN.1 production,
> replace:
> version AttCertVersion DEFAULT v1,
> with:
> version AttCertVersion --version is v2,
> 
> b) In clause 12.1 replace the AttCertVersion ASN.1 production with:
> AttCertVersion ::= INTEBER {v2(1) }
> 
> c) In clause 12.1 replace the AttCertIssuer ASN.1 production with:
> AttCertIssuer ::= SEQUENCE {
> 	issuerName GeneralNames OPTIONAL,
> 	baseCertificateID [0] IssuerSerial OPTIONAL,
> 	objectDigestInfo [1] ObjectDigestInfo OPTIONAL }
> 
> d) Replace the first paragraph that follows the ASN.1 with the following:
> The version differentiates between different versions of the attribute
> certificate. For attribute certificates issued in accordance with the
> syntax in this specification, version must be v2.
> 
> e) The same changes listed in bullets a), b), and c) must also be made in
> Annex A in the attributeCertificateDefinitions module.
> 
> 12. Editor's Response:
> 
> Accepted solution proposed by source