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