Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 5 May 2004 22:44:57 -0700

Comments inline, marked with [bcr]:

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sean P. Turner
Sent: Tuesday, March 02, 2004 8:45 AM
To: Blake Ramsdell
Cc: [email-masked]
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

---

From: "Tony Capel" <[email-masked]>
Date: Mon, 10 May 2004 14:14:08 -0400

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Blake Ramsdell
| Sent: May 6, 2004 1:45 AM
| To: 'Sean P. Turner'
| Cc: [email-masked]
| Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt

cut .....| 

| 
| 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.

I would argue that it is not the presence of the CRL which is the concern,
rather it is the use of the signing time provided by the signer to verify CRL
validity which is the base concern.  In fact this same concern applies if the
signing time is used to judge whether the certificate is expired or not (CRL's
may not include cert serialNumber for revoked expired certs).

Please see:
http://www.imc.org/ietf-smime/mail-archive/msg01855.html 

and possibly the security caution following would suffice?:

"The signing time in the message cannot be trusted if the signing key
has been compromised.  Thus the signing time should not be used as
the "current time" when performing certificate expiry or revocation
checking as per KEYM."

Tony