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

Comments:

1. Para 1, 2nd sentence: Replace "MUST certify that the public" with "MUST verify that the public".
2. 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?
3. Para 1.1, Certificate definition: Replace "binds an entity's distinguished name" with "binds an entity's name".
4. Para 2.3, 5th para,  Can add a pointer to the path building ID/RFC from PKIX?
5. 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"
6. 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)
   
7. 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?
   

Cheers,

spt