Comments inline, marked with [bcr]:
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Sean P.
Turner
Sent: Tuesday, March 02, 2004 8:45 AM
To: Blake Ramsdell
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
Para 1, 2nd sentence: Replace "MUST certify that the public" with "MUST
verify that the public".
[bcr] Fixed.
Para 1.1, ASN.1 references- Why do these point to X.680-680 while the
2633bis ASN.1 references point to X.208-209. Shouldn't they point to the
same thing?
[bcr] Fixed.
Para 1.1, Certificate definition: Replace "binds an entity's
distinguished name" with "binds an entity's name".
[bcr] Fixed.
Para 2.3, 5th para, Can add a pointer to the path building ID/RFC from
PKIX?
[bcr] Hoo. Dangerous. There seems to be blocking risk here that I don't
think is warranted (that is, when is draft-ietf-pkix-certpathbuild going
to be completed?) I'm leaving it out for right now.
Para 2.3, 5th para 2nd sentence, Replace "Other methods of building
certificate chains may be supported" with "Other methods of building
certificate chains MAY be supported"
[bcr] Fixed.
Para 5: I'd like to add a security consideration about why it might not
be good to send CRLs: "CRLs sent with the message impose concern when
the signer's certificate is revoked, but the signer purposely includes a
valid CRL but not the most recent CRL without the signer's serialNumber
thereby providing a false verification". (or something like that)
[bcr] I took a hack at this. If there's any concerns, we'll address them
in IETF-wide last call.
Para 5: The last 4 reasons for a signature and certificate checking to
fail are may not be true if the sig/cert is checked at some future date
after an initial check. Should we add a note to indicate that if the
signature or certificate is verified at some later date they should be
considered "valid" even though one of the four things occurred?
[bcr] I'm not feeling it -- the spirit of this guidance is that "at some
particular point in time when validating a certificate, these things
could fail" without talking about how those failures might be corrected
in the future. I think that's outside the scope, and the point is to
illustrate that at some particular time, some particular things might go
wrong.
Blake