The one change that might hit CMS is the ability to use PGP keys. It
depends on if we want to do this just for encryption or for both encryption
and signing.
Jim
-----Original Message-----
From: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Russ
Housley
Sent: Tuesday, March 29, 2016 10:39 AM
To: Erik Andersen <era(_at_)x500(_dot_)eu>
Cc: IETF SMIME <smime(_at_)ietf(_dot_)org>
Subject: Re: [smime] Message takeover attacks against S/MIME
Erik:
CMS already has a content type that supports AEAD algorithms. There will
probably need to be some documents that specify the conventions for using
new
AEAD algorithms, but I do not anticipate any changes to CMS itself.
Russ
On Mar 29, 2016, at 4:25 AM, Erik Andersen <era(_at_)x500(_dot_)eu> wrote:
Does any of proposed action for S/MIME affect CMS?
Erik
-----Oprindelig meddelelse-----
Fra: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] På vegne af Jim Schaad
Sendt: 28 March 2016 18:49
Til: 'Sean Turner' <sean(_at_)sn3rd(_dot_)com>; 'Wei Chuang'
<weihaw(_at_)google(_dot_)com>
Cc: 'IETF SMIME' <smime(_at_)ietf(_dot_)org>
Emne: Re: [smime] Message takeover attacks against S/MIME
I am open to suggestions, but until somebody gives be a better answer I
do not
know how to do the following:
* A better mechanism than sign-encrypt-sign to get both
authentication and
confidentiality (or at least a non-strippable way of doing it)
Using and AEAD algorithm only solves part of the problem as one can do
an
encrypt-sign but the outer integrity cannot be validated by a third party.
This is
also set to be able for third parties to add the outer signature layer and
that has
been used in several specifications so it is not clear to me that this is
one issue
that needs to be fixed.
I do to totally agree that we need to start moving to AEAD algorithms
however.
jim
-----Original Message-----
From: smime [mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Sean
Turner
Sent: Monday, March 28, 2016 6:11 AM
To: Wei Chuang <weihaw(_at_)google(_dot_)com>
Cc: IETF SMIME <smime(_at_)ietf(_dot_)org>
Subject: Re: [smime] Message takeover attacks against S/MIME
If the patient is on the table, then all of these look like items
we?d need to address.
spt
On Mar 26, 2016, at 09:57, Wei Chuang <weihaw(_at_)google(_dot_)com>
wrote:
Some more work item suggestions (I'm posting on behalf of someone
who
wishes to avoid the rough and tumble of discussion on the mailing
list though reads it):
* Making ECC an official part of S/MIME, RFC5753 is only
informational.
* Authenticated encryption.
* A better mechanism than sign-encrypt-sign to get both
authentication and
confidentiality (or at least a non-strippable way of doing it)
* Dropping obsolete ciphers and hashes from the spec: drop SHA-1, MD5,
etc.
* A modernized RFC 4134 (practical examples of S/MIME messages, it
could
avoid the fiasco of 3rd party forgetting ASN-1 tags in their messages).
-Wei
On Sun, Mar 13, 2016 at 9:38 AM, Wei Chuang <weihaw(_at_)google(_dot_)com>
wrote:
Some interesting usability consideration were raised on the PKIX
list by Martin
Rex in the thread "another attempt to canonicalize local parts" that
could be addressed by a rechartered WG. He points out problems with
- Incompletely specified cert chains preventing signature verification
i.e.
missing CA certs and no ability to fetch them. Fully specifying the
chains would resolve this.
- Reverifying old "archived" emails on his MUA not possible as the
certs have
expired. Fixing a verification time on delivery or other scheme is
desirable.
-Wei
On Thu, Mar 10, 2016 at 11:12 AM, Wei Chuang
<weihaw(_at_)google(_dot_)com>
wrote:
On Mon, Mar 7, 2016 at 10:58 PM, Russ Housley
<housley(_at_)vigilsec(_dot_)com>
wrote:
I am hearing interest in these topics (a combination of things on
this list and
side conversations).
(1) Specify the way to use authenticated encryption in S/MIME. Note
that it is
already done for CMS.
(2) Specify conventions for AES-CCM, AES-GCM, and ChaCha20 with
Poly1305
authenticated encryption algorithms.
(3) Specify conventions for using Curve25519 and Curve448 for key
agreement.
(4) Specify conventions for using the CFRG chosen curves for
elliptic curve
digital signature.
(5) Specify a way to use PGP public keys in addition to PKIX
certificates.
Anything else?
While I'm afraid of scope creep as resolving the above would be very
useful,
could also mail header integrity and privacy be considered? Perhaps
the WG scope be split into near and long term work to help prioritize.
The above five items be categorize as near term and the mail header
work considered longer term?
-Wei
(PS yes there is RFC7508 which is experimental, and does not keep
private the
sender and recipient. Still it is an improvement...)
Is this enough to re-charter the S/MIME WG?
Russ
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime