Skip to main content

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 steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) (was Discuss) No Objection

No Objection (2004-05-30)
Reviewed by Spencer Dawkins, Gen-ART

The new section 1.3 describing version numbers resolves my DISCUSS. Thanks!

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2004-05-25)
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 steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) Recuse

Recuse ()