All,
I agree with the majority of Jim's comments with the following responses
in-line:
At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
John,
1) Sec 1, 1rst para: Please make the following change:
[Jim Schaad: What is the benifit of putting in the ITU-T reference? Is it
not sufficent to reference just PKIX?]
[JSP: Agree. Just refer to PKIX.]
10) Sec 4.2, 1rst para, last sent: Please change:
OLD: "This is necessary when a) verifying a signature from a correspondent
and, b) creating a digital envelope with the correspondent as the intended
recipient."
NEW: "This is necessary before using a public key to provide security
services such as: verifying a signature; encrypting a content-encryption key
(ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be
used to encrypt or decrypt a content-encryption key."
[Jim Schaad: Please remove "or decrypt" in the last sentence. In some
circumstances there is no need to verify the senders certificate for a
simple decryption operation. What do I care if the sender's certificate has
been revoked, it will still decrypt and that is all I care about.
Encryption does not carry any information about authentication.]
[JSP: I agree with your sentence "In some circumstances there is no need to
verify the senders certificate..". However, in some circumstances, people
care very much. With the D-H, KEA and other key agreement algorithms, the
recipient forms a pairwise key with the originator using the originator's
public key as a part of this process. The pairwise key is then used to
decrypt the content-encryption key which is then used to decrypt the
content. My experience has been that people do care about the identity of
the originator when a pairwise key is formed. How about if we add the
following sentence: "If an envelopedData object is received in which the
recipient's copy of the content encryption key is protected using a key
agreement algorithm, then the recipient organization's policy may include
processing requirements that omit the validation of the originator's
certification path before using the originator's public key to form the
pairwise symmetric key as part of the decryption process."]
Names for chaining
JSP: IMHO, the existing text is fine, so please delete this bullet.
Jim Schaad: I am not sure that I agree with this. There are now more ways
of chaining and we should add these in or at least acknowledge them.
[JSP: The PKIX X.509 Certificate and CRL Profile, Sec 6, Pass Processing
bullet a.4 states that the cert path validation software must ensure that:
"(4) the subject and issuer names chain correctly. (If the certificate has
an empty sequence in the name field, name chaining will use the critical
subjectAltNames and issuerAltNames fields.)" I believe that this statement
satisfies the requirement to document alternate strategies for chaining.
Furthermore, since the S/MIME CERT spec (Sec 3.1, last para) requires that
the subject and issuer DNs MUST be populated in S/MIME-compliant certs
(except for the end-entity cert subject DN which may be empty), then the DNs
required for chaining MUST always be present in S/MIME certs.]
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================