jsp(_at_)jgvandyke(_dot_)com (John Pawling) writes:
Eric,
Thank you for your excellent work on the draft-ietf-smime-x942-00 I-D.
I have the following minor comments and questions:
1) Sec 2.1.1: Please change the following:
OLD: "In CMS, the recipient's key is identified by the CMS
RecipientIdentifier, which points to the recipient's certificate. The
sender's key is identified using the OriginatorIdentifier field,
either by reference to the sender's certificate or by inline inclusion
of a key."
NEW: "In CMS, the recipient's key is identified by the CMS
RecipientIdentifier, which points to the recipient's certificate or
directly to the recipient's key (via the subjectKeyIdentifier). The
sender's public key is identified using the originatorIdentifierOrKey
field, either by reference to the sender's certificate, sender's
public key (via the subjectKeyIdentifier) or by inline inclusion of
the sender's public key."
I have no problem with this.
2) Sec 2.1.2: The "[2]" tag is not needed in the following syntax
because the first occurrence of OCTET STRING is mandatory, so the
ASN.1 decoders can uniquely identify each OCTET STRING (i.e. pubInfo
and counter).
OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
pubInfo [2] OCTET STRING OPTIONAL,
}
KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
counter OCTET STRING SIZE (4..4) }
This is there for bits on the wire compatibility with X9.42,
which has two other fields here which we're not using.
3) Sec 2.1.2: This section states: "pubInfo is a random string
provided by the sender. In CMS, it is provided as a parameter in the
UserKeyingMaterial field (a 512 bit byte string)." Since pubInfo is
defined as an OCTET STRING, shouldn't the value of pubInfo be
expressed in octets (i.e. bytes)? When you wrote "(a 512 bit byte
string)", did you mean "(an OCTET STRING containing 64 octets)"?
That's fine with me. I think this text came from Russ. Russ?
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."