Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 02 Mar 2004 11:44:31 -0500

Comments:

Para 1, 2nd sentence: Replace "MUST certify that the public" with
"MUST verify that the public".

Para 1.1, ASN.1 references- Why do these point to X.680-680 while
the 2633bis ASN.1 references point to X.208-209. Shouldn't they point
to the same thing?

Para 1.1, Certificate definition: Replace "binds an entity's
distinguished name" with "binds an entity's name".

Para 2.3, 5th para,  Can add a pointer to the path building
ID/RFC from PKIX?

Para 2.3, 5th para 2nd sentence, Replace "Other methods of
building certificate chains may be supported" with "Other methods of
building certificate chains MAY be supported"

Para 5: I'd like to add a security consideration about why it
might not be good to send CRLs: "CRLs sent with the message impose
concern when the signer's certificate is revoked, but the signer
purposely includes a valid CRL but not the most recent CRL without the
signer's serialNumber thereby providing a false verification". (or
something like that)

Para 5: The last 4 reasons for a signature and certificate
checking to fail are may not be true if the sig/cert is checked at some
future date after an initial check. Should we add a note to indicate
that if the signature or certificate is verified at some later date
they should be considered "valid" even though one of the four things
occurred?

Cheers,

spt

---

From: "Tony Capel" <[email-masked]>
Date: Wed, 3 Mar 2004 12:42:58 -0500

Minor additional comment (not a show stopper) related to Sean's number 6
comment:

| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Sean P. Turner
| Sent: March 2, 2004 11:45 AM
| To: Blake Ramsdell
| Cc: [email-masked]
| Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt
| 
| <<cut>>
|
| 6.  Para 5: I'd like to add a security consideration about why it 
| might not be good to send CRLs: "CRLs sent with the message 
| impose concern when the signer's certificate is revoked, but 
| the signer purposely includes a valid CRL but not the most 
| recent CRL without the signer's serialNumber thereby 
| providing a false verification". (or something like that)
| ....

IF this is added, it may also make sense to emphasize that the transmission of
root certificates may also be a problem (Para 2.3 paragraph 4 uses "SHOULD NOT"
in the context of accepting root certificates - this may not raise the issue
strongly enough).  A caution in the Security section something like:

"The ability of a receiver to adopt a self-signed certificate received within a
messages should be
strongly controlled to prevent the inadvertent adoption of root certificates.
The ability of a sender
to transmit self-signed certificates should be controlled to ensure that they
cannot
unexpectedly send root certificates which may potentially alter the trust
settings of receiving entities. Some implementers may choose to permit the
disabling of the ability to send and process-upon-receipt self-signed
certificates."

Some enterprise environments may want to disable the ability of their desktops
to accept or send root certificates in messages.

Tony

---

From: "Sean P. Turner" <[email-masked]>
Date: Thu, 04 Mar 2004 06:55:10 -0500

I agree with Tony's comment.  It is in the same vein and should be added.

spt

---

From: "Sean P. Turner" <[email-masked]>
Date: Thu, 04 Mar 2004 07:00:05 -0500

David P. Kemp wrote:

>
> Blake,
>
> Thanks for clarifying the requirement to support certificates
> without email addresses.
>
> Comments:
>
> 1.  Section 2.3 para 4: "Agents MAY send CA certificates, that is,
> certificates that are self-signed and can be considered the "root"
> of other chains."   This incorrectly implies that the only kind
> of CA cert is the self-signed kind.  Suggest "Agents MAY send
> CA certificates that are self-signed and ..."
>
> 2.  Section 4.4 paragraph 2: Why must sending and receiving
> agents correctly handle the listed extensions only when they
> appear in end-entity certificates?  Suggest that sending and
> receiving agents MUST correctly (i.e. in accordance with RFC 3280)
> handle the basic constraints, key usage, AKI, SKI, and SAN extensions
> in end-entity *and CA* certificates.
>
> 3.  Section 4.4.1 paragraph 3: "Certificates SHOULD contain a
> basicConstraints extension in CA certificates and SHOULD NOT contain
> that extension in end entity certificates."  In order to avoid
> inconsistency with PKIX, change to "Certificates MUST contain a
> basicConstraints extension in CA certificates and SHOULD NOT contain
> that extension in end entity certificates."  In other words, a
> sending and receiving agent is non-compliant if it accepts
> a v3 certificate without the basicConstraints extension as a CA
> certificate.
>
> Dave

Dave,

I think the 1st and 3rd comments are editorial, but the 2nd corrects 
something that was wrong.  I hope that implementors didn't just handle 
the extensions in EE certs but instead did the right thing and handled 
the extensions in CA certs as per 3280.

spt

---

From: "Tony Capel" <[email-masked]>
Date: Mon, 8 Mar 2004 15:23:23 -0500

This may be falling into the crack between S/MIME and PKIX.

I do not think this needs a change in any of the documents, although
something in the security section MIGHT be appropriate (as below).

I have seen it proposed that the signing time be used when validating
signatures, and at least one S/MIME implementation may do this.
I THINK this violates the intent of CERT section 4.1 and rfc3280
(KEYM) sections 3.3 and 6.3.3.

That is, "current time" in these rfc's should not be interpreted to
be equivalent to the "signing time" from the message.
 
Sean Turner's recent comment #6, 2 March 2004 on CERT is also relevant.

This was discussed back in 1998 and I think responsibility allocated
to KEYM (PKIX).  The unique S/MIME WG issue is the improper (IMHO) use
of the signing time in the message to judge certificate expiry or CRL
validity (of course KEYM does not mention signing time).

Denis Pinkas wrote (28 Sept 1998, in part):

"...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...."

Alternatively stated:

An attack is for a forger to set their local clock back to a time prior 
to the revocation, forge the message and enclose a then-current (old) 
CRL in the message. If the signing time is used to select the CRL the 
forger could succeed (the forger might mount a DOS attack to prevent the
receiver getting a more recent CRL). Alternatively, the forger waits for
certificate expiry and then compromises the key, back-dates their forged
signature
- and again the attack is successful even if the rightful owner knows about
it (since revocation support is not guaranteed past expiry).

I think the following are correct:

1. The certificate is checked for expiry, and if unexpired, the
current and not "too old" CRL is used (or OCSP server, etc. accessed).
Specifically the check for expiry AND "too old" must be based on
the receiver's sense of time, NOT the signing time.
(Ideally it would be based on a trusted time source but this is
normally not available, so this should not be mandatory.
If there is a trusted time stamp other options are available).

2. If the certificate is expired, no CRL (or OCSP) check is
done since the CA does not guarantee revocation processing.
CRL checking should not be done even if a cached "old" CRL
is available (e.g. as provided within the message).
This has consequences when attempting to (re-)verify old
messages stored in inBoxes for example.
They may verify when received, but fail when re-verified later.
This is bad for users, and implementers may be tempted to provide
a "better" solution by using the signing time (bad).
If a signature on an incoming message is important,
users must consider using (prior to cert expiry)
a trusted time stamp server or trusted archive so a
"trusted time" can be added. Enterprise users might consider
automating this; e.g. ensuring that old e-mails (and CRLs!!)
are archived in a trusted and timely manner. 

Should a sentence be added cautioning users against using the untrusted
signing time from the message for certificate expiry and CRL validity
checking?

For example something like:

"The signing time in the message cannot be trusted if the signing key
has been compromised.  Thus the signing time should not be used as
the "current time" when performing certificate expiry or revocation
checking as per KEYM."

Tony

PS: A quote from Peter Sylvester (30 July 2003) in the PKIX WG discussion:

"Isn't creating a digital signature which is not 
almost immediately presented to some relying or attesting party 
a profound misunderstanding of cryptographic techniques? "

Unfortunately we must live with e-mail application reality!

PPS: There is a long discussion, (starting in about 30 July 2003) 
in the PKIX WG on related issues including potential archiving of CRL's.
I think for current purposes we just need to emphasize that "signing time"
is untrusted and must not be used for expiry or CRL validity testing. Going
beyond that might get too complicated and best left with PKIX.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Mar 2004 21:49:39 -0800

Blake,

A couple of small issues:

1.  Do we need to review the  RSA key sizes on certificate verification,
4096 is soon to be a common key size I think and should be supported.  I
don't know that 512 should not be dropped from MUST to SHOULD.

2.  I just noticed that 4.4.2.1 does not have a corresponding section for
RSA.  In point of fact this may now be in CMSALG and therefore not needed.
(i.e. remove 4.4.2.1)

jim