Russ,
Thank you very much for addressing my comments. I agree with all of your
responses and recommendations except I have the following commments:
1) You proposed:
"UnauthAttribute ::= SEQUENCE {
authAttrType OBJECT IDENTIFIER,
authAttrValues SET OF AttributeValue }"
Recommend:
"UnauthAttribute ::= SEQUENCE {
unAuthAttrType OBJECT IDENTIFIER,
unAuthAttrValues SET OF AttributeValue }"
2) [JSP1:
7) Sec 6.3, first 3 paras: IMHO, the first 3 paragraphs of Sec 6.3 should
be replaced with: "The content-encryption key for the desired
content-encryption algorithm is generated at random. The data to be
protected is padded as described below. The padded data is then encrypted
using the content-encryption key. The encryption operation maps an
arbitrary string of octets (the data) to another string of octets (the
ciphertext) under control of a content-encryption key. The encrypted data
is included in the envelopedData encryptedContentInfo encryptedContent OCTET
STRING."
These are the paragraphs that I believe should be deleted because I believe
that they are obsolete and are not required for S/MIME v2 backwards
compatibility:
"The input to the content-encryption process is the "value" of the
content being enveloped. Only the content octets; identifier or
length octets are not included.
When the content being enveloped has content type of data (as defined
in section 4), then just the value of the data (e.g., the contents of
a file) is encrypted. This has the advantage that the length of the
content being encrypted need not be known in advance of the
encryption process.
The identifier octets and the length octets are not encrypted. The
length octets may be protected implicitly by the encryption process,
depending on the encryption algorithm. The identifier octets are not
protected at all, although they can be recovered from the content
type, assuming that the content type uniquely determines the
identifier octets. Explicit protection of the identifier and length
octets requires that the signed-data content type be employed prior
to digital enveloping."]
[Russ:
I do like your lead in paragraph. However, the fact that the tag and length
octets are not encrypted needs to be preserved.]
[JSP2: When you say "tag and length octets", do you mean the tag and length
octets of the envelopedData encryptedContentInfo encryptedContent OCTET
STRING? If so, then I agree with your comment and please see below for
exact wordsmithing requests.
If that is not what you meant, then please explain. Please don't assume
that the data to be encrypted is always ASN.1 encoded. There may not always
be ASN.1 tag and length octets at the beginning of the plaintext content
that must be encrypted. For example, the data to be encrypted may be the
contents of a file containing ASCII characters (with no leading ASN.1 tag
and length octets).]
[Russ:
How about:
The content-encryption key for the desired content-encryption algorithm is
randomly generated. The data to be protected is padded as described below,
then the padded data is encrypted using the content-encryption key. The
encryption operation maps an arbitrary string of octets (the data) to another
string of octets (the ciphertext) under control of a content-encryption key.
The encrypted data is included in the envelopedData encryptedContentInfo
encryptedContent OCTET STRING.]
[JSP2: Fine so far.]
[Russ:
The input to the content-encryption process is the "value" of the content
being enveloped. Only the content octets are encrypted; the tag and the length
octets are not included. The length octets may be protected implicitly by the
encryption process, depending on the encryption algorithm. The tag octets are
not protected at all, although they can be recovered from the content type,
assuming that the content type uniquely determines the identifier octets.
Explicit protection of the identifier and length octets requires that the
signed-data content type be employed prior to digital enveloping.]
[JSP2: Recommend that the following sentence replace the aforementioned text:
"Note that only the value octets of the envelopedData encryptedContentInfo
encryptedContent OCTET STRING are encrypted; the OCTET STRING tag and length
octets are not encrypted."]
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================