Peter,
I agree that the Password-based Encryption spec should not include
requirements for setting the EnvelopedData version field. I agree that the
rfc2630bis spec is the correct document in which to specify the
EnvelopedData version-setting algorithm. I proposed that the rfc2630bis
spec, Section 6.1, EnvelopedData version-setting algorithm should be changed
as follows: (same as proposed in my 7/2 reply to Russ and 7/5 reply to Jim):
[*** NEW ***] version is the syntax version number. The
appropriate value depends on originatorInfo, RecipientInfo, and
unprotectedAttrs. The version MUST be assigned as follows:
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures are pwri CHOICE) OR
(any RecipientInfo structures are ori CHOICE)
THEN version is 3
ELSE
IF (originatorInfo is present) OR
(unprotectedAttrs is present) OR
(any RecipientInfo structures are a version other than 0)
THEN version is 2
ELSE version is 0]
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Tuesday, July 10, 2001 1:21 PM
To: John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com;
jimsch(_at_)exmsft(_dot_)com;
rhousley(_at_)rsasecurity(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
"Jim Schaad" <jimsch5(_at_)home(_dot_)com> writes:
I do not think that the EnvelopedData version number field was ever
addressed
in the Peter's document. I agree that the algorithm needs to be updated.
That was deliberate, I don't see that a new RecipientInfo definition (or
anything similar) should be placing contraints on RFC 2630. If there's a
need
to change EnvelopedData then it should be done where it's defined, not in an
external document.
(While I'm commenting on this, I also feel that the best way to resolve this
is
to issue a draft which leaves the issue unspecified, then in the next draft
write down what it is that implementations are doing, which will ensure that
(a) it's consensus behaviour and (b) the RFC reflects the real world.
Trying
to second-guess the behaviour of implementations seems risky at best).
Peter.