Subject: 8/26/98 S/MIME WG Minutes

From: [email-masked] (John Pawling)
Date: Fri, 18 Sep 1998 13:22:45 -0400

All,

This message includes the minutes of the IETF S/MIME Working Group (WG)
meeting held on 26 August 1998 in Chicago, IL.  These minutes have been
coordinated with the briefing presenters.  All briefing slides are stored
at: ftp://ftp.ietf.org/ietf/smime/.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley
 
Russ reviewed the agenda.  Nobody objected to the agenda.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MSG Draft Discussion - Blake Ramsdell

Blake stated that the 6 Aug 98 S/MIME v3 Message Specification (MSG)
Internet Draft (I-D) includes the comments submitted to the S/MIME WG mail
list.  He  stated that the application/MIME text was deleted from MSG and
the X.509 references were changed to PKIX references.  When asked if there
were any other comments to the MSG I-D, the room was silent.  When asked how
many people had read the MSG I-D, not many in the room raised their hands.
Blake stated that the MSG I-D has been submitted for last call within the
S/MIME WG and that there are no other changes planned for the MSG I-D. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERT Draft Discussion - Blake Ramsdell

Blake stated that the 6 Aug 98 S/MIME v3 Certificate Handling (CERT) I-D
includes the comments submitted to the S/MIME WG mail list.  He stated that
the CERT I-D has been submitted for last call within the S/MIME WG.  When
asked how many people had read the CERT I-D, not many in the room raised
their hands.  Blake stated that the X.509 references were changed to PKIX
references.  There was a comment from an attendee that Section 3.2 "Required
Name Attributes" should be deleted because it is redundant to the PKIX X.509
Certificate and CRL Profile (PKIX Part I).  Nobody objected to this change.
There was a comment from an attendee who was concerned that certificates
included in S/MIME messages may divulge sensitive information.  The
consensus of the attendees was that this is a matter to be solved by the
policy of the local organization of the user who is releasing the S/MIME
message.  The group decided that no change is required in the S/MIME I-Ds
regarding this issue.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ESS Draft Discussion - Paul Hoffman

Paul stated that the 5 Aug 98 Enhanced Security Services for SMIME (ESS) I-D
has been submitted for last call within the S/MIME WG.  When asked how many
people had read the ESS I-D, not many in the room raised their hands.  Paul
stated that the EntityIdentifier syntax needs to be added to the ESS I-D
ASN.1 module as noted on the S/MIME WG mail list.  He stated that the S/MIME
ASN.1 modules need to be compiled by various ASN.1 toolkits to determine if
there are any other discrepancies.  Van Dyke and Associates (VDA)
volunteered to compile the ESS and CMS I-D ASN.1 modules using the SNACC
ASN.1 compiler, but others were urged to check the ASN.1 with their own
compilers as well.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS Draft Discussion - Russ Housley

Russ presented briefing slides (see ftp://ftp.ietf.org/ietf/smime/)
regarding the open issues related to the June 98 Cryptographic Message
Syntax (CMS) I-D.  Russ stated that the ESS, CERT and MSG I-Ds are dependent
on the CMS I-D; therefore, those I-Ds will not complete WG Last Call until
the CMS I-D completes WG Last Call.  When CMS enters WG Last Call, then all
of the I-Ds will be final after the two-week last call period is complete.
In summary, the WG last call period will simultaneously close for the CMS,
ESS, CERT and MSG I-Ds. 

Slide #1: CMS Document Status:  All CMS sections are complete except for
Section 12 that will document the mandatory algorithms and some optional
algorithms.  The comments received on the mail list have been incorporated
into a CMS draft that has not yet been released to the WG.  A draft of
Section 12 was discussed on the mail list.  The most recent draft is
included in the 22 July message, subject: "CMS Section 12, take 3".  The
completion of Section 12 depends on the Diffie-Hellman (D-H) Key Agreement
Method I-D <draft-ietf-smime-x942-00.txt>.

Slide #2: Message Digest Algorithms: 

SHA-1 is mandatory to implement.  The AlgorithmIdentifier syntax includes an
optional parameters field.  There was some debate regarding whether the
parameters field should be absent or set to an ASN.1 NULL (05 00 hex) when
the SHA-1 OID is populated in the AlgorithmIdentifier syntax.  Eric Rescorla
and Blake pointed out that current implementations encode the field as an
ASN.1 NULL.  The attendees decided that the CMS I-D will state that the
parameters must be encoded as an ASN.1 NULL, but that CMS implementations
should be able to accept either an ASN.1 NULL or absent parameters.  This is
required for compatibility with S/MIME v2.     

MD5 is optional to implement.  The attendees decided that the CMS I-D will
state that the parameters must be encoded as an ASN.1 NULL when the MD5 OID
is populated in the AlgorithmIdentifier syntax.  This is required for
compatibility with S/MIME v2.     

Slide #3: Signature Algorithms:  

DSA-with-SHA1 is mandatory to implement.  The attendees decided that the CMS
I-D will state that the parameters must be absent (not ASN.1 NULL).  This is
required for consistency with PKIX Part I.

RSA-with-SHA1 and RSA-with-MD5 are optional to implement.  With both of
these combinations, the rsaEncryption OID must be used in the signedData
signerInfo signatureAlgorithm.  The digesting algorithm is indicated in the
signedData signerInfo digestAlgorithm.  The attendees decided that the CMS
I-D will state that the parameters must be encoded as an ASN.1 NULL when the
rsaEncryption OID is populated in the AlgorithmIdentifier syntax.  This is
required for compatibility with S/MIME v2.     

Slide #4: Key Management (KM) Algorithms: 

The group discussed which KM algorithms and key encryption algorithms should
be documented in CMS.  The attendees decided that the most important
algorithms to cover are the mandatory-to-implement algorithms.  The
attendees agreed that optional algorithms not already covered in CMS can be
documented in separate I-Ds. 

The proposed Section 12 text states that static D-H (as specified in the D-H
I-D) will be mandatory to implement.  CMS will document how static D-H can
be used to generate a key-encryption key (KEK) for use with Triple DES.  It
will also document how static D-H can be used to generate a KEK for use with
RC2. 

When obtaining the bits of the KEK, the minimal number of bits needed to
form the KEK must be used (a.k.a. key reduction).  There is an open issue
regarding how the minimal number of bits is obtained for RC2.  The group
decided that this issue will be debated on the list.

The group decided that CMS should not discuss the use of D-H to generate
keys for DES.  

The group decided that CMS should specify that at least 512 modulus should
be used.

An attendee asked about key recovery.  Russ stated that this issue has been
thoroughly discussed on the mail list and that discussion identified at
least three ways to implement key recovery without specifying a specific
strategy in CMS. 

Slide #5: Key Management (KM) Algorithms 2:  Mail List Key (MLK) encryption
is optional to implement.  CMS will discuss the use of Triple-DES and RC2 to
be used for MLK purposes.

Slide #6: Key Wrapping Algorithm:  CMS will document a single
mandatory-to-implement key wrapping strategy to be used with key agreement
and MLK (but not key transport).  Jim Schaad asked if an OID should be
defined to identify the wrapping algorithm.  Russ answered that the X9.42
D-H OID used in conjunction with CMS implies the wrapping algorithm.  John
Pawling pointed out that Sec 12.4, 3rd paragraph states: "Triple-DES may be
an exception here; the same identifier is used for both 2-key and 3-key
Triple DES.  This is probably easily handled by always wrapping three keys,
even if the first and third keys match."  John stated that these issues need
to be resolved to avoid interoperability problems. 

Slide #7: Content Encryption Algorithms:  Triple-DES in CBC mode is the
mandatory-to-implement algorithm.  The DES-EDE3-CBC OID will be used.   The
group decided that DES will not be documented in CMS. 

Slide #8: Content Encryption Algorithms 2: The group decided that CMS will
document RC2 in CBC mode as a "should" to implement (rather than "may").
The RC2-CBC OID will be used.

Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
algorithm.  The wording in CMS will be: "If authenticatedData is
implemented, then HMAC-with-SHA1 must be implemented."  The group also
decided that DES MAC will not be included in CMS as an optional algorithm.

Slide #10: Way Forward:  When Section 12 is completed, then CMS will be
ready for last call.  Russ asked if there were any other issues.

1) Denis Pinkas asked if there was a way to verify the "correctness" of a
CMS message.  Dennis considers signature generation time to be a critical
factor in determining whether or not that signature is valid.  If the
signing key is revoked, then the signing time would indicate if the message
signed before or after the revocation date.  John Pawling pointed out that
the MSG I-D already states that the signingTime attribute should always be
included in signed messages.  The attendees agreed that wording was sufficient.

2) Denis also was concerned that the serial number in the signer's cert is
not covered by the signedData signerInfo signature, so a different cert
could be substituted for the signer's cert.  Russ stated that the SIGATTR
I-D addresses this issue.

3) Doug Maughn asked about the processing requirements for generating a
countersignature.  It was proposed on the list that the generator of a
countersignature must validate the original signature before generating the
countersignature.  Russ has included that proposal in the CMS draft that he
has not yet published.  He stated that "validate" means verify the signature
value of the CMS signedData, not necessarily validate the signer's cert path.

4) John Linn proposed that text should be added to the Security
Considerations section regarding the use of PKCS #1 v2.  The group agreed
that this was a good idea.  John Linn agreed to provide the text for the
Security Considerations section of CMS.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X9.42 Draft Discussion - Russ Housley

The D-H Key Agreement Method I-D (a.k.a. D-H I-D) is required before CMS can
progress to WG Last Call.  After the D-H I-D was published to the list, Russ
asked if there were any patents that applied to the D-H variant documented
in the I-D.  Certicom announced on the list that they have applied for a
patent that covers the variant of the D-H algorithm specified in the D-H
I-D.  He proposed two alternatives: 1) CMS and D-H I-Ds could continue to
mandate the current D-H variant; or 2) WG could pursue a different D-H
variant as the mandatory-to-implement KM algorithm to avoid the delay
associated with working out the licensing agreement with Certicom.

Russ presented a slide describing another variant.  The variant currently
documented in D-H I-D is called Static-Static (S-S) D-H.  With S-S D-H, the
originator has a static key and the recipient has a static key both of which
are contained in certificates.  The alternative is called Ephemeral-Static
(E-S) D-H.  With E-S D-H, the recipient has a static key contained in a
certificate, but the originator generates an ephemeral key not contained
within a certificate.  Russ stated that the E-S D-H would need to be
documented and then distributed to determine if there are any patents or
pending patents that apply to the E-S D-H variant.  He stated that the E-S
D-H has some of the same properties as the Open PGP D-H strategy, but not
identical.  Paul Hoffman noted that there have been no patent statements
made regarding the Open PGP D-H strategy. 

Russ presented the following info:

          S-S D-H              |         E-S D-H
-------------------------------|--------------------------------
Pending patent                 | No patents (?)
1 exponentiation per recipient | 2 exponentiations per recipient
Data origin authentication     | No authentication
Shorter certificate            | Longer certificate (p,q,g) 
			       | (about 200 bytes longer)
Originator cert in message     | Originator cert not in message
Common p,q,g parameters        | Use recipient's p,q,g values

The question was asked if q is really required to be transmitted in the CMS
heading.  Russ stated that q should be included so that the existing X9.42
ASN.1 syntax for the p,q,g parameters can be used.  Also, the q value can be
used to validate the p and g values.    

Darren Harter pointed out that there is another option in which the
originator would produce a self-signed E-S D-H cert and include it in the
message.

Tim Dierks from Consensus Development Corporation/Certicom spoke regarding
Certicom's pending patent that they believe covers the X9.42 D-H variant.
Tim stated that Certicom is willing to issue a royalty-free license to
S/MIME and PKIX vendors to use the technology covered by their pending
patent. Tim stated that any applicant must divulge their own patents and
pending patents that would block the implementation of the mandatory
requirements of PKIX or CMS.  Tim stated that Certicom will require that the
applicant issue a royalty-free license to Certicom covering the applicant's
patented technology.   Tim stated that Certicom intends to gain revenue for
use of the technology in "non-S/MIME" cases.

Eric Rescorla pointed out that the S/MIME WG's acceptance of this option
would limit future vendor's options.  He also pointed out that CMS is used
in applications other than S/MIME, so the Certicom's offer does not benefit
all users of CMS.

Paul pointed out that there is not an official definition of "S/MIME", so
the limitation to issue licenses to "S/MIME" vendors is problematic.  Paul
also pointed out that there will probably be future versions of the S/MIME
specifications.  Paul reiterated Eric's statement that CMS is used in
applications other than S/MIME.

Jeff Schiller, the IETF Security Are Co-Director, expressed his desire to
avoid a situation in which licenses must be obtained to implement
mandatory-to-implement features.  He was concerned with the restrictions
placed by Certicom's proposal regarding how CMS is to be used.  Jeff stated
that he had difficulty with the "S/MIME" limitation included in Certicom's
offer because not all CMS implementers would be able to obtain the
royalty-free license.  Jeff stated that he liked the E-S D-H option better
than the S-S D-H option due to technical reasons in addition to the patent
issues.  Jeff stated that he has found that the two exponentiations required
to be calculated for each recipient in the E-S D-H option is acceptable as
far as performance is concerned.

John Pawling pointed out that some vendors are implementing CMS/ESS security
libraries that could be used by "S/MIME" or "non-S/MIME" applications, so
this further complicates the issue.  He pointed out that the E-S option
eliminates the need to validate the originator's KM cert, so a significant
time saving is achieved.  He recommended that the WG should pursue both the
E-S D-H and S-S D-H options in parallel.  Several attendees agreed with this
plan.

Dave Solo pointed out that some environments consist of an "S/MIME"
application on one end of a transaction and a "non-S/MIME" application on
the other end.  Dave also asked if there was an issue with using the E-S D-H
option with forming a pairwise key with yourself.  Russ stated that that
there will not be a problem with that operation.

Tim stated that he would obtain more info from Certicom.  Later in the
meeting after talking with Certicom via telephone, Tim stated that Certicom
agreed to provide royalty-free licenses for all uses of CMS, not just for
use in "S/MIME" applications.  Tim stated that the license would also cover
the use of S-S D-H in future versions of the CMS and PKIX specifications
(not just S/MIME v3). 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

SIGATTR Draft Discussion - Jim Schaad

Jim used slides for his two presentations.  Jim stated that the 2 July 98
Signing Certificate Attribute Specification (SIGATTR) I-D has been submitted
to the S/MIME WG mail list.  Jim stated that he would incorporate the
comment regarding replacing the IssuerAndSerialNumber field with
IssuerSerial so that Attribute Certificates can be identified.

There was some debate regarding whether the CertID certHash value should be
changed so that it is optional.

Jim asked if the attendees believe that the SIGATTR text should be
incorporated into CMS as a "MAY implement" option.

Paul agreed that the Signing Certificate Attribute should be included as a
"MAY implement" option in CMS.   

Dave Solo stated that he would like an enhancement to be made to the Signing
Certificate Attribute syntax to allow the identification of the complete
cert path of the signer (not just signer's cert).  This enhancement is
required so that the recipient can determine the context of the signer's
signature by examining the cert path of the signer's cert.  This issue
requires further debate on the list.

It was agreed that the SIGATTR text would not be incorporated into CMS until
all issues are resolved.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim stated that the 6 July 98 Certificate Distribution (CERTDIST) I-D has
been submitted to the S/MIME WG mail list.  Jim stated that the open issues
identified include:

1) Lack of content within the published message.  He considers this one
closed and that there will not be a content.  

2) Ability of CA and RA to publishing information on behalf of the user.
Through discussion with others, he has determined that the best solution
requires an extension in the RA's cert.  Issue: Is this overly broad for CAs
to issue?  Jim's current position is that only users can create these messages. 

Issue:  Is the fact that any parent CA could issue this and the fact that a
new Extension is required a problem.  Jim's current position is that the
risks out-weigh the benefits and that only users can create these messages.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that the 15 July 98 Domain Security Services using S/MIME
(DOMSEC) I-D has been submitted to the S/MIME WG mail list.  When asked how
many people had read the DOMSEC I-D, many in the room raised their hands.
Bill presented the briefing slides stored on ftp://ftp.ietf.org/ietf/smime/.
These slides presented the basic points made in the DOMSEC I-D.  There were
no significant issues raised.  The question was asked from the floor (by
Paul Hoffman) as to the future plans for the document.  Bill said he was
happy to allow the working group to make that decision.  Paul said that the
DOMSEC I-D contained protocol, so it could not be progressed as an
informational document.  Chris Bonatti suggested that the protocol could be
moved into CMS, allowing the document to become informational.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Revocation Info in CMS - Paul Hoffman

Paul proposed that the message originator should be able to include non-CRL
revocation status information in the CMS heading "in case the recipient of
the message cannot (or does not want to) get the status information when
validating the signature, such as if the recipient is not online and no
usable CRLs were included in the SignedData."  For example, an OCSP response
could be included in the CMS heading.  This could be done via a new
attribute or by enhancing the CMS CRL list syntax.  This proposal requires
further debate on the list. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked for a straw poll of the attendees regarding which options the WG
should continue to pursue regarding the "mandatory-to-implement" KM issue.
The results are as follows:

1) Pursue S-S D-H option: about 20 hands raised

2) Pursue E-S D-H option: about 50 hands raised

3) Pursue self-signed E-S- D-H option: 0 hands raised

Based on this straw poll, options 1 and 2 will be pursued in parallel.  Russ
will investigate whether there are any patent issues with the E-S D-H
option.    Russ asked Tim Dierks to post further info regarding the Certicom
license offer.

======================================================
John Pawling                         [email-masked]

J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 25 Sep 1998 21:24:10 +0100

A few comments.

> required for consistency with PKIX Part I.

I presume it is implied that a NULL parameter should be tolerated. I
know of some implementations that generate NULL.

> The RC2-CBC OID will be used.

Will this include the number of bits that may/should be supported as
well?

> included in signed messages.  The attendees agreed that wording was sufficient.

IMHO this may need an additional comment.

For example should the valdity (i.e. expiry) of the signing certificate
chain use the current time or the signingTime? 

The signingTime attribute cannot be trusted in many cases.

If a certificate is revoked due to key compromise an attacker could
generate a message with a signingTime before it was revoked.

The corollary to this is that if a certificate has been revoked then the
posession of a signed message with a signingTime before the revokation
time is not sufficient for nonrepudiation purposes. Some corroboration
as to the signing time is required: such as a trusted timestamp
countersignature. 

> value of the CMS signedData, not necessarily validate the signer's cert path.

Does "verify the signature value of the CMS signedData" imply that just
the digital signature of the signedData is checked or the messageDigest
value as well, implying that the original content must be checked?

IMHO checking signedData is tolerable but the original content
verification has very serious implications, as I've mentioned before.

Even so this affects some existing implementations: for example the
Verisign AuthentiCode timestamper just takes the signedData signature
and produces a trusted timestamp countersignature from that.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 26 Sep 1998 01:33:11 +0100

I may have misinterpreted things, appologies. I wasn't objecting to the
minutes as such but making comments about the points raised. I couldn't
comment on the minutes: I wasn't there :-)

I'll just expand a little on my comment about tolerating NULL with DSA.
I've now had time to check Netscape Messenger in 4.06. It uses NULL
everywhere including SMIMECapabilities when signing using DSA with SHA1.
This isn't intended as a criticism of the Netscape implementation: it
probably pre-dates the recommendation.

I'll leave mentioning the rest until the other points are raised in due
course.

Steve.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Sep 1998 12:17:06 -0700

Dr Stephen Henson has sent a few comments:

> > CMS message.  Denis considers signature generation time to be a critical

Well, I don't think that "the attendees agreed that wording was sufficient" is the
right wording since I said during the last session in Chicago, that I would
reformulate a message sent on July 15, about :

1) the signature generation time,
2) the identification of the certificate.

The first item is precisely the topic raised by Stephan.

In the original message I was going straight to text replacement proposals with
insufficient explanations. Hereafter more explanations are provided, but, as
advertised, the text will be much longer. :-(

On page 10, the text says “ The input to the signature validation process includes
the result of the message digest calculation process and the signer’s public key”.

There is no information given here on the process by which the signer's public key is
obtained. If a wrong public key or a revoked key is being used, then the end result
of the verification process will be erroneous.

CMS can be used with real time communications or with store and forward environments,
i.e. within or without a S/MIME context. With real time communications, the signer’s
public key is either known from the context or will be extracted from the CMS syntax.
With store and forward environments, it is always be extracted from the CMS syntax.
This is where the danger lies.

It seems natural to use the issuerAndSerialNumber from the SignerInfo. The danger of
using it directly, without any additional control, is mentioned partly (i.e. one half
of it) in the document draft-ietf-smime-sigattr-01.txt [SIGATTR]... but no reference
is made to this document in CMS.

The danger here is to substitute a certificate by another one that would contain the
same public key value, since the issuerAndSerialNumber from the SignerInfo is NOT
part of the signature process. That situation may arise at least in two occasions:
the user has multiple certificates for the same public key from different CAs or a
malicious CA issues a certificate for a different entity while copying the public key
from another certificate. In the first case, a certificate that is different from the
certificate intended to be used by the signer is presented to the verifier, while in
the second case some "bad" CAs, i.e. omitting to perform POP -Proof of Possession of
the private key, cannot be detected. Full details are in [SIGATTR].

Substitutions can be detected by signing a Certificate Identifier.

However this is still insufficient to address the issue. The second part of it has to
do with key compromise. If a key is compromised, then the corresponding certificate
will be revoked. It is important to know if the certificate was revoked or not AT THE
TIME OF THE SIGNATURE. If it is not possible to know the time of the signature, then
unpredictable results may occurs in case of key compromise.

Although  John [Pawling] pointed out that the MSG I-D already states that the
signingTime attribute should always be included in signed messages, CMS can be used
in wider environments and thus people looking at CMS will not necessarily look at the
MSG I-D.

In addition, there are two unsolved problems with this approach:

1) the signingTime attribute alone does NOT solve the issue,
2) the current text of CMS is misleading on this issue. The current text of section
11.3 on page 29 says:

" No requirement is imposed concerning the correctness of the signing time, and
acceptance of a purported signing time is a matter of a recipient's discretion.  It
is expected, however, that some signers, such as time-stamp servers, will be trusted
implicitly."

The signingTime attribute only reflects the time the signer wanted to be included.
The signer may well pre-date that value, ... but more important, if the key of the
signer is compromised then an attacker may also pre-date that value. In such a
situation it cannot be made a difference between a past "honest" signature from the
right signer and a pre-dated "fake" signature from an attacker. This difference is
not important when CMS is used in real time contexts since the latest CRL or
equivalent will be used. However, if CMS is used in non repudiation contexts, then it
is important to be able to settle the dispute. The use of a Time Stamping Server can
then allow to make the difference between "good" and "fake" signatures.

Since CMS will be used in S/MIME environments but also in non-S/MIME environments as
a successor of PKS#7, we have two options either correct the text in the section 5.6
and 11.3 (on page 29) or provide more awareness in the "Security consideration
section" on page 40.

If the first option is chosen, then here is a full text replacement for that section:

" 5.6  Message Signature Validation Process

The input to the signature validation process includes the result of the message
digest calculation process and the signer's public key. It is fairly important to
pick up the right signer's public key, valid at the time the signature was made.

The signer’s public key can be known in advance from the context. In such a case it
may be used directly. When this is not the case, it has to be obtained from the
information present in the CMS message. If the issuerAndSerialNumber from the
SignerInfo is used, then a substitution of certificates containing the same public
key value is possible. If such a substitution is a concern then the threat can be
addressed by making the certificate identifier part of the signature as described in
the Signing Certificate Attribute Specification [SIGATTR]. In such a case the right
public key is contained in the certificate pointed by the signed certificate
identifier.

In order to make sure that this identified certificate is valid, e.g.using CRLs and
ARLs, it is important to know the status of the certificate at the time the signature
was performed.

If no time information is present in the CMS structure, then the assumption should be
that the message has just be signed. In that case the revocation information valid at
the time the verification is performed will be used.

If only the signingTime attribute is present, then no direct assumption can be made
on the time of the signature. If the certificate is not presently revoked and still
valid, then the time included in the signingTime attribute can be taken as the one
placed by the genuine signer and the certificate can be accepted. If the certificate
is presently revoked and/or no more valid, the verifier is at a risk to use
inadequate revocation information unless additional assurance may be obtained about
the time of the signature (see next).

If a counter signature from a trusted time Stamping Authority is used in addition to
the signingTime attribute and if these two time values are "close" enough (e.g. a few
hours) then the assumption should be that the signing time is the time mentioned in
the signingTime attribute. The revocation information that was valid at that signing
time should then be used.

The details of the signature validation depend on the signature algorithm employed.

The recipient may not rely on any message digest values computed by the originator.
If the signedData signerInfo includes signedAttributes, then the content message
digest must be calculated as described in section 5.4.  For the signature to be
valid, the message digest value calculated by the recipient must be the same as the
value of the messageDigest attribute included in the signedAttributes of the
signedData signerInfo."

In order to address the text from section 11.3 on page 29, here is a text
replacement.

" The signing time is only the purported signing time as indicated by the signer. No
further assurance can be given upon the accuracy of that time unless additional
assurance can be obtained through other means, e.g. a counter-signature from a Time
Stamping Server. In particular, it should be noticed that in case of key compromise,
the message can be signed by an attacker that may use a pre-dated time, i.e. a time
in the past when the certificate was not revoked. In such a case, unpredictable
results may occur."

The changes I have provided are rather conservative from the current structure. The
Signing Certificate Attribute Specification [SIGATTR] addresses two topics. One has
to do, as the title indicates it, with Attribute Certificates while the other has to
do with the certificate identifier from the signer. It would/might be better to move
the section relative to the certificate identifier from SIGATTR into CMS since this
is just another VERY "useful attribute" from the section 11.

> as to the signing time is required: such as a trusted timestamp

I think that the new text proposal provided hereabove may address your perfectly
valid concern.

> and produces a trusted timestamp countersignature from that.

Denis

FYI, follows the original text from July 15.

-----------------------------------------------------------------

Without waiting for a last call for CMS-06, here are my comments:

On page 10, the text says “ The input to the signature validation
process includes the result of the message digest calculation process
and the signer’s public key”. This is not sufficient in order to give
the same and relaible result between two different implementations. The
knowledge of the certificate of the signer as well as the time of the
signature are both important. If there is an ambiguity on one or the
other component then the end-result can be different.

1) About the CertUid of the signer

Unless the unambiguous identifier of the certificate of the signer is
part of the signed attributes, attacks are possible. This is a weakness
of the original PKS-7 document that should be corrected.

This has already be advertised on the PKIX list and explained during the
last meeting in LA. This relates to the POP (Proof of Private key
possession) issue. In other words, using the certificate identifier from
the signer as an additional signed attribute is the only way to make
sure, and at the time the verification is performed, that the user
really has possession of the signing private key, whether or not the CA
has done POP correctly. This protects again a malicious CA that would
"forget" to make POP.

This discussion also relates about the way to uniquely identify a
certificate. From previous E-mail exchanges it has been demonstrated
that in some cases the hash of the issuer public key was a way to
discriminate between synonymous issuer names. Thus the syntax of the
certificate identifier should be extended to optionally support a hash
of the issuer key.

2) About the signature time

Unless the time is securely known (using a time stamp over the CMS
message), the time should be considered to be the time at which the
signer makes the verification. This means that different results may be
obtained since the signer’s certificate may have been revoked since the
signature was produced (see the recent E-mails exchanges on the mailing
list).

In order to care for these cases, the following text is proposed as an
addition after the first sentence of the section 5.6:

 “ The signer’s public key can be known in advance from the context. In
that case it is directly used. When this is not the case, it has to be
obtained from the information present in the message. The CertUid
present in the signed certificate shall be used for that purpose.

In order to make sure that the identified certificate is valid, e.g.
using CRLs and ARLs, it is important to know the status of the
certificate at the time the signature was performed. When that time
cannot be reliably known, then, by default, the current time shall be
used. It should be noticed that this can lead to different results
depending upon the time the validation is performed. When that time is
reliably known, e.g. using a time stamp over the CMS message, then that
time shall be used. It should be noticed that leads to the same result
whatever the time the validation is performed.”

The section 11 should be extended to add the "CertUid" as a "usefull"
attribute.

At the last meeting in LA, I explained during the S/MIME session why it
is important to allow for the presence of a CertUid as a signed
attribute. Refer to the slides that I presented. This section should be
expanded to allow that attribute to be included here, otherwise there
would be serious security problems.

Proposed text:

11.X  Certificate Unique Identifier

   The Certificate-Unique-Identifier attribute type specifies
   unambiguously the certificate to be used for verifying the
   signature, when it is not known otherwise from the context.

   A Certificate-Unique-Identifier attribute must have a single
   attribute value.

   The following object identifier identifies the
   Certificate-Unique-Identifier attribute:

      id-certUid OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          XXXX }

   Certificate-Unique-Identifier attribute values have ASN.1 type
   CertUid:

      CertUid ::= CertId

      CertId ::= SEQUENCE {
          issuerAndSerialNumber    IssuerAndSerialNumber,
          hashIssuerPublicKey      HashIssuerPublicKey  OPTIONAL}

   The IssuerAndSerialNumber type identifies a certificate, and
   thereby an entity and a public key, by the name of the certificate
   issuer and an issuer-specific certificate serial number.

   The hashIssuerPublicKey allows to discriminate between two CAs
   that would have the same issuer name. Should that situation happen,
   then the two CAs would have different public keys. The hash of the
   public keys would thus be different.

      HashIssuerPublicKey ::= SEQUENCE {
            hashOid                 ObjectIdentifier,
            hashedIssuerPublicKey   OCTET STRING}

On page 5, there is a sentence stating: “The signer’s certificate may be
included in the SignedData certificates field”. It is not clear why the
whole certificate should be included. The CertUid (or CertID) would be
sufficient. If the full certificate is needed it does not need to be
part of the signed attributes (note that it is not part of the list of
“useful attributes” described in the section 11).

[Text deleted]

Denis