Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt

From: "Tony Capel" <[email-masked]>
Date: Fri, 8 Aug 2008 15:40:39 -0400

Sean:

I know you will be putting in some text to address Jim (and my) request for text
re key sizes > 4096 for CERT 3850bis.

A directly related security concern, and one that has been around for some time,
is the potential for other inappropriate processing if an offered end entity
cert (or any offered cert in the chain) is processed prior to, or irrespective
of, being validated to a trusted root.  In addition to the problem of a large
key, there is the potential of inappropriate CDP (and/or AIA) defined action
(e.g. web access to an inappropriate address).  Rfc5280 [KEYM] has a comment*
about making sure that such an action does not download malicious code, but in
practice even correctly formed CDP/AIA access(es) could raise denial of service
or privacy concerns.  Normally a user agent will time out on an invalid CDP/AIA
address; but certificates can contain many addresses....  Also, the CDP/AIA
address could point to a special address defined by the originator, e.g.
allowing a spammer to validate receipt of a signed message (even if the
signature fails).

So I wonder, for CERT, whether it would be best to be more general when
identifying these security concerns so that issues in addition to the key size
are included?

Some possible text (for CERT only):

"In addition to the Security Considerations identified in [KEYM], caution should
be taken when processing certificates which have not first been validated to a
trust anchor.  Certificates could be manufactured by untrusted sources for the
purpose of mounting denial of service or other attacks.  For example, keys
selected to require excessive cryptographic processing, or extensive lists of
CDP and/or AIA addresses in the certificate, could be used to mount denial of
service attacks.  Similarly, originator-specified CDP and/or AIA addresses could
be inserted into certificates to allow the originator to detect receipt of the
message even if signature verification fails."

The above would just identify the concern, not offer any solutions - I suggest
leaving how to be cautious up to the implementer! 

Finally, I am still concerned that we are not making support for (RSA) 4096 bit
keys FOR CERTIFICATE SIGNATURE VERIFICATION ONLY mandatory, i.e. in section 4.3
of 3850bis.  In practice this size is widely supported today, e.g. both MS and
Mozilla have many 4k certs in their root stores**.
The discussion here is verification only, NOT signature generation or decryption
- mandating support for these I agree needs to be limited to 2k; the typical
crypto size limit for hardware tokens.  However, signature verification is not
normally done in the token anyway; so this is not an issue.  In practice many
authorities are going to 4k root certs because they want to issue them with long
lifetimes (longer than end user certs, so shorter keys in end user certs are
ok).  We need to make sure common e-mail clients building to v3.2 can work with
these common new 4k RSA root certs.  This comment ONLY affects support for cert
signature processing (3850bis section 4.3, and even then maybe only for
Certificates, not CRLs).

Tony

*Abstract from KEYM:
  "Implementers should be aware of risks involved if the CRL
   distribution points or authority information access extensions of
   corrupted certificates or CRLs contain links to malicious code.
   Implementers should always take the steps of validating the retrieved
   data to ensure that the data is properly formed."

** See GeoTrust Universal CA in both MS and Mozilla root stores.

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: July 28, 2008 4:18 PM
| To: [email-masked]
| Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
| 
| 
| 
| Other things Jim requested offline:
|  - Point to PKIXALG as opposed to CMSALG, which makes sense 
| since this is the CERT ID.
|  - Add back in changes from v3 to v3.1, which also makes 
| sense because the section should not have been removed.
| 
| spt
| >-----Original Message-----
| >From: Jim Schaad [mailto:[email-masked]]
| >Sent: Monday, July 28, 2008 2:43 PM
| >To: Sean P. Turner; 'Blake Ramsdell'
| >Cc: [email-masked]
| >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
| >
| >Comments on the draft.
| >
| >In section 4.4.3, I find the following text confusing:
| >
| >End-entity certificates contain an extension that 
| >   constrains the certificate from being an issuing authority 
| >   certificate (see Section 4.4.2).
| >
| >
| >I believe that this text might be better as it clarifies what
| >is being stated.  I.e. it is not the fact that basic 
| >constraints is being used which actually does the mentioned 
| constraint.
| >
| >
| >End-entity certificates contain the Key Usage extension which
| >restraints the end-entity from using the key to perform 
| >issuing authority operations (see
| >4.4.4)
| >
| >Also the previous comment (on 3851bis) on key sizes > 4096
| >should be applied to this document
| >
| >jim
| >
| >> -----Original Message-----
| >> From: [email-masked] [mailto:owner-ietf-
| >> [email-masked]] On Behalf Of [email-masked]
| >> Sent: Tuesday, July 01, 2008 1:30 AM
| >> To: [email-masked]
| >> Cc: [email-masked]
| >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
| >> 
| >> A New Internet-Draft is available from the on-line Internet-Drafts
| >> directories.
| >> This draft is a work item of the S/MIME Mail Security 
| >Working Group of
| >> the IETF.
| >> 
| >> 	Title		: Secure/Multipurpose Internet Mail Extensions
| >> (S/MIME) Version 3.2 Certificate Handling
| >> 	Author(s)	: S. Turner, B. Ramsdell
| >> 	Filename	: draft-ietf-smime-3850bis-04.txt
| >> 	Pages		: 20
| >> 	Date		: 2008-6-30
| >> 
| >> This document specifies conventions for X.509 certificate usage by
| >>    Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. 
| >> S/MIME
| >>    provides a method to send and receive secure MIME messages, and
| >>    certificates are an integral part of S/MIME agent processing. 
| >> S/MIME agents validate certificates as described in RFC 
| 3280bis, the
| >>    Internet X.509 Public Key Infrastructure Certificate and CRL
| >> Profile.
| >>    S/MIME agents must meet the certificate processing 
| requirements in
| >>    this document as well as those in RFC 3280bis. This document
| >>    obsoletes RFC 3850.
| >> 
| >> A URL for this Internet-Draft is: 
| >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
| >> 
| >> Internet-Drafts are also available by anonymous FTP at: 
| >> ftp://ftp.ietf.org/internet-drafts/
| >> 
| >> Below is the data which will enable a MIME compliant mail reader
| >> implementation to automatically retrieve the ASCII version of the 
| >> Internet-Draft.
| >
|

---

From: "Turner, Sean P." <[email-masked]>
Date: Sat, 9 Aug 2008 18:45:42 -0400

>-----Original Message-----

Snip

>"In addition to the Security Considerations identified in 
>[KEYM], caution should be taken when processing certificates 
>which have not first been validated to a trust anchor.  
>Certificates could be manufactured by untrusted sources for 
>the purpose of mounting denial of service or other attacks.  
>For example, keys selected to require excessive cryptographic 
>processing, or extensive lists of CDP and/or AIA addresses in 
>the certificate, could be used to mount denial of service 
>attacks.  Similarly, originator-specified CDP and/or AIA 
>addresses could be inserted into certificates to allow the 
>originator to detect receipt of the message even if signature 
>verification fails."
>
>The above would just identify the concern, not offer any 
>solutions - I suggest leaving how to be cautious up to the 
>implementer! 

Since Paul's replacement text removes the part about path validation I like
the idea of moving it to CERT.  Not sure I understand the last sentence (how
is the originator going to insert fields in their certificate)?  I also
don't want to loose the ideas that we had in MSG about ensuring only trusted
keys are used before use and that a time-out isn't a bad idea. That is I'd
like to keep the following text:

One approach would require that the corresponding public key certificate be
validated to a trust anchor prior to use, thus ensuring that only trusted
public keys are used.  However, some implementations may choose to perform
signature verification (or key establishment for encryption) in parallel
with certificate validation, even if certificate validation fails.  In such
cases, measures should be  included to limit the impact, for example by
limiting cryptographic  processing time or requiring certificate validation
prior to the use of large keys. 

>Finally, I am still concerned that we are not making support 
>for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION 
>ONLY mandatory, i.e. in section 4.3 of 3850bis.  In practice 
>this size is widely supported today, e.g. both MS and Mozilla 
>have many 4k certs in their root stores**.
>- mandating support for these I agree needs to be limited to 
>2k; the typical crypto size limit for hardware tokens.  
>However, signature verification is not normally done in the 
>token anyway; so this is not an issue.  In practice many 
>authorities are going to 4k root certs because they want to 
>issue them with long lifetimes (longer than end user certs, so 
>shorter keys in end user certs are ok).  We need to make sure 
>common e-mail clients building to v3.2 can work with these 
>common new 4k RSA root certs.  This comment ONLY affects 
>support for cert signature processing (3850bis section 4.3, 
>and even then maybe only for Certificates, not CRLs).

Unless I've misread my email from before, Paul objected to having
requirements on the verifiers that are in excess of the  signers and that
it's really more of a current practice as opposed to an interoperability
requirement.  Paul correct me if I'm wrong.

---

From: "Tony Capel" <[email-masked]>
Date: Mon, 11 Aug 2008 10:54:09 -0400

| 
| >-----Original Message-----
| 
| Snip
| 
| >Some possible text (for CERT only):
| >
| >"In addition to the Security Considerations identified in
| >[KEYM], caution should be taken when processing certificates 
| >which have not first been validated to a trust anchor.  
| >Certificates could be manufactured by untrusted sources for 
| >the purpose of mounting denial of service or other attacks.  
| >For example, keys selected to require excessive cryptographic 
| >processing, or extensive lists of CDP and/or AIA addresses in 
| >the certificate, could be used to mount denial of service 
| >attacks.  Similarly, originator-specified CDP and/or AIA 
| >addresses could be inserted into certificates to allow the 
| >originator to detect receipt of the message even if signature 
| >verification fails."
| >
| >The above would just identify the concern, not offer any
| >solutions - I suggest leaving how to be cautious up to the 
| >implementer! 
| 
| Since Paul's replacement text removes the part about path 
| validation I like the idea of moving it to CERT.  Not sure I 
| understand the last sentence (how is the originator going to 
| insert fields in their certificate)? 

"Insert" may have been a misleading. I meant that its pretty
 easy* for an originator to create an end user cert
 (and possibly zero or more intermediate certificates)
 with selected content (including bad keys, arbitrary CDP/AIA
 URI entries, etc.)). These would not validate to a trust
 anchor, but IF they are processed anyway, the originator could
 get a receiver to use a large key, execute a specified URI, etc.
 So for CERT the problem is not only bad keys.

I do not suggest addressing anything other than bad keys in
 MSG, since I think the above additional issues (other certificate
 content) is a CERT processing issue not an MSG issue.  (For MSG its
 only the use of a key requiring excessive processing, and
 the mitigation measures are related to MSG crypto processing 
 and your point about time-out is good for MSG.)

|                                       I also don't want to 
| loose the ideas that we had in MSG about ensuring only 
| trusted keys are used before use and that a time-out isn't a 
| bad idea. That is I'd like to keep the following text:
| 
| One approach would require that the corresponding public key 
| certificate be validated to a trust anchor prior to use, thus 
| ensuring that only trusted public keys are used.  However, 
| some implementations may choose to perform signature 
| verification (or key establishment for encryption) in 
| parallel with certificate validation, even if certificate 
| validation fails.  In such cases, measures should be  
| included to limit the impact, for example by limiting 
| cryptographic  processing time or requiring certificate 
| validation prior to the use of large keys. 
| 

| >Finally, I am still concerned that we are not making support
| >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION 
| >ONLY mandatory, i.e. in section 4.3 of 3850bis.  In practice 
| >this size is widely supported today, e.g. both MS and Mozilla 
| >have many 4k certs in their root stores**.
| >The discussion here is verification only, NOT signature 
| >generation or decryption
| >- mandating support for these I agree needs to be limited to 
| >2k; the typical crypto size limit for hardware tokens.  
| >However, signature verification is not normally done in the 
| >token anyway; so this is not an issue.  In practice many 
| >authorities are going to 4k root certs because they want to 
| >issue them with long lifetimes (longer than end user certs, so 
| >shorter keys in end user certs are ok).  We need to make sure 
| >common e-mail clients building to v3.2 can work with these 
| >common new 4k RSA root certs.  This comment ONLY affects 
| >support for cert signature processing (3850bis section 4.3, 
| >and even then maybe only for Certificates, not CRLs).
| 
| Unless I've misread my email from before, Paul objected to 
| having requirements on the verifiers that are in excess of 
| the  signers and that it's really more of a current practice 
| as opposed to an interoperability requirement.  Paul correct 
| me if I'm wrong.

This does not impose differing requirements on smime signers and
verifiers. I think both smime signers and verifiers need 4k 
support for certificate (and CRL) verification only.  I expect
these 4k certificates and CRLs to be created by certificate
authorities so only they need to create the 4k signatures. 

Tony

* i.e. the perpetrator could set up a CA and generate these certificates.

>>cut

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 20 Aug 2008 17:26:24 -0400

Tony,

I incorporated these comments in a version I'm about to post.  Minor tweaks
to the text for the CERT security considerations.

spt

>From: Tony Capel [mailto:[email-masked]] 
>Sent: Friday, August 08, 2008 3:41 PM
>To: 'Turner, Sean P.'; [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
>
>Sean:
>
>I know you will be putting in some text to address Jim (and 
>my) request for text re key sizes > 4096 for CERT 3850bis.
>
>A directly related security concern, and one that has been 
>around for some time, is the potential for other inappropriate 
>processing if an offered end entity cert (or any offered cert 
>in the chain) is processed prior to, or irrespective of, being 
>validated to a trusted root.  In addition to the problem of a 
>large key, there is the potential of inappropriate CDP (and/or 
>AIA) defined action (e.g. web access to an inappropriate 
>address).  Rfc5280 [KEYM] has a comment* about making sure 
>that such an action does not download malicious code, but in 
>practice even correctly formed CDP/AIA access(es) could raise 
>denial of service or privacy concerns.  Normally a user agent 
>will time out on an invalid CDP/AIA address; but certificates 
>can contain many addresses....  Also, the CDP/AIA address 
>could point to a special address defined by the originator, e.g.
>allowing a spammer to validate receipt of a signed message 
>(even if the signature fails).
>
>So I wonder, for CERT, whether it would be best to be more 
>general when identifying these security concerns so that 
>issues in addition to the key size are included?
>
>since this 
>| is the CERT ID.
>sense because 
>| the section should not have been removed.
>| 
>| spt
>| >I believe that this text might be better as it clarifies what is 
>| >being stated.  I.e. it is not the fact that basic constraints is 
>| >being used which actually does the mentioned
>| constraint.
>| >
>| >
>| >restraints the end-entity from using the key to perform issuing 
>| >authority operations (see
>| >4.4.4)
>| >
>should be 
>| >applied to this document
>| >
>| >jim
>| >
>http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
>| >>