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".
- 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?
- Para 1.1, Certificate definition: Replace "binds an entity's
distinguished name" with "binds an entity's name".
- Para 2.3, 5th para, Can add a pointer to the path building
ID/RFC from PKIX?
- 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"
- 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)
- 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