RE: S/MIME version number and Attribute Certificates

Dave,

I have stated my argument in previous messages that changing the AC syntax
changes the signedData and envelopedData syntaxes because the AC syntax is
an integral part of those syntaxes.  I don't have anything else to add to
that argument.  Recommend that you review the rfc2630bis draft and provide
comments to the proposed changes included in that draft.

===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: David P. Kemp [mailto:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Tuesday, April 24, 2001 11:04 AM
Cc: 'ietf-smime(_at_)imc(_dot_)org'
Subject: Re: S/MIME version number and Attribute Certificates


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