More draft comments -- primarily section 5

["Blake Ramsdell" <blake@xxxxxxxxxxxxxxxxxx>]

Some more comments about the current draft, focusing on section 5.

Most (all?) references to "DH-DSS" should be "DSS".  This may have been
brought up before.

When referring to certificates and CRLs, we should use consistent
terminology (the exact name used for the files, minus the file extensions),
as opposed to narrative.

I think that in general, we should adopt a convention for describing what's
to be expected in the examples.  For instance, for section 5, document the
exact order of the certificates and CRLs.

Section 5.2 Alice's certificate from the message does not match
AliceRSASignByCarl.cer

Section 5.4 Certificates contain AliceRSASignByCarl, CarlDSSSelf and
AliceDSSSignByCarlNoInherit (doesn't match narrative or the dump).
SigningTime attribute is incorrectly encoded with GeneralizedTime instead of
UTCTime.

Section 5.5 Alice's certificate from the message does not match any
certificate (including AliceRSASignByCarl).

Section 5.6 "Two SignedDatas" should be "Two SignerInfos"

Section 5.7 the printed form of the dump shows AliceRSASignByCarl is
included, but 5.7.bin only has AliceDSSSignByCarlNoInherit included.

Section 5.8 the file 5.8.eml appears to only use CR for the EOL character.
This should probably be CRLF.  The text in the draft does not match the
contents of the message.  The .eml file does not appear to have a
MIME-Version header.

Section 5.9 same comments for 5.8.  Additionally, the content is not legal
S/MIME -- it needs a leading CRLF in order to satisfy the requirements of
having a MIME entity (the CRLF will make the content implicit text/plain).

Section 5.11 is not specific about which certificates are found in the
message.  I think to be consistent, it should document which certificates
are contained (Alice and Carl's)

CarlDSSCRLEmpty.crl gives the Java 2 SDK fits when parsing.  This could very
well be a Java 2 issue, and I'll investigate further.

Blake
--
Blake Ramsdell
Brute Squad Labs