John,
I stand corrected on RecipientInfo, which contains no certificates,
attribute or otherwise. I was thinking of CertificateSet, which as
you say is included in SignedData and the OriginatorInfo field of
EnvelopedData.
RFC2630's CertificateChoices contains:
attrCert [1] IMPLICIT AttributeCertificate,
and unless I misunderstood your proposal, it would have continued to
contain the identical attrCert field with the identical Context 1
tag. Were you proposing to add a new CHOICE option?, i.e.
2000attrCert [2] IMPLICIT AttributeCertificate
If so, I believe a new context tag is unnecessary. If not, then
I believe that the syntax of SignedData, EnvelopedData, and any
other structure which incorporates CertificateSet is not changed,
only the syntax of AttributeCertificate itself is changed.
Russ gets your point that v1 and v2 attribute certificates
are not compatible. Perhaps I'm dense, but I still don't get
it. I have two draft X.509 documents which say:
1997: AttributeCertificateInfo ::= SEQUENCE {
version Version DEFAULT v1, -- shall be v1
subject CHOICE {
.
.
}
2000: AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion DEFAULT v1, -- can be v1 or v2 - NOT!
owner Owner,
.
.
}
I understand that 2000's owner is a SEQUENCE and 1997's subject is
a bare choice. And perhaps there is still a defect in the latest draft
of 2000 which permits v1 to be used with the SEQUENCE syntax. But
if v1 is used exclusively for ACs with the 1997 syntax and v2 is used
exclusively for the 2000 syntax, then a decoder can determine
how to interpret the rest of the AC after examining the version field.
ACs are an example of proper incrementing of a version number. PKCs are
an example of unnecessary incrementing because v2 and v3 follow the
rules of extensibility from v1.
Whether or not X.509 incorrectly permits v1 to be used in 2000-syntax
ACs, a 1997 CMS decoder should be able to detect that it has found
garbage in a CertificateChoice [1] field and proceed to process the
message after ignoring the garbage. I believe that is a better solution,
regardless of AC deployment history, than incrementing the SignedData
and EnvelopedData versions and forcing 1997 decoders to discard entire
messages.
Regards,
Dave
"Pawling, John" wrote:
Dave,
I have some comments regarding statements made in your message:
1) You stated: "specific issue of RIs containing V2 ACs". None of the
RFC2630 RecipientInfo CHOICE types are capable of containing ACs.
2) You stated: "The version number contained within an Attribute Certificate
is sufficient in principle for a decoder of an outer object (EnvelopedData)
to determine whether the inner (AC) version is supported,..." I disagree
with your use of the terms "outer object" and "inner object". The AC syntax
is an integral part of the SignedData and EnvelopedData syntaxes which are
the "outer objects". Changing the AC syntax changes the SignedData and
EnvelopedData (a.k.a. "outer") syntaxes. I still believe that incrementing
the version number when v2 ACs are used is the technically correct position
and is consistent with the use of version numbers in other specs. For
example, when the X.509 certificate and AC syntaxes changed, new version
numbers were defined. I retracted my comment because it seemed that nobody
has operationally used 1997 ACs in SignedData and EnvelopedData objects. If
that is the case, then implementers can design their code to handle only the
new 2000 AC syntax (because the 1997 AC syntax was never used).
3) You stated: "I don't buy the argument that some tools don't do the right
thing and that a
data standard should therefore do the wrong thing (increment
EnvelopedData)." I don't believe that anybody made this argument. I know
that I did not.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================