Cryptographic Message Syntax (CMS)
draft-ietf-smime-rfc3369bis-04
Yes
(Steven Bellovin)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Scott Hollenbeck)
(Thomas Narten)
Recuse
(Russ Housley)
Note: This ballot was opened for revision 04 and is now closed.
Steven Bellovin Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
(was Discuss)
No Objection
No Objection
(2004-05-30)
Unknown
Reviewed by Spencer Dawkins, Gen-ART The new section 1.3 describing version numbers resolves my DISCUSS. Thanks!
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2004-05-25)
Unknown
Nits:
Odd stitching in 5.1:
certificates is a collection of certificates. It is intended that
the set of certificates be sufficient to contain certification
paths from a recognized "root" or "top-level certification
authority" to all of the
signers in the signerInfos field.
In 6.2.2 I think the following text is a bit unclear:
Implementations MUST support recipient processing
of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
Implementations that do not support key agreement algorithms that
make use of UKMs MUST gracefully handle the presence of UKMs.
Possibly a term other than "processing" would help; would "MUST accept
a KeyAgreeRecipientInfo SEQUENCE...." before leading into the following
make sense?
Following its predecessors, this doc describes generalizedTime as
UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and
MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the
number of seconds is zero. Midnight (GMT) MUST be represented as
"YYMMDD000000Z". Century information is implicit, and the century
MUST be determined as follows:
Is it time to update this to actually say "UTCTime values MUST be expressed
with reference to Coordinated Universal Time (formerly known as Greenwich
Mean Time or Zulu clock time) and must..."? Note also spurious space in the
doc at 11.3.
Thomas Narten Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
Recuse
Recuse
()
Unknown