Phillip:
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.
If we are going to do this, I would like to also look at automating
enrollment for a CA issued certificate.
I agree that getting and renewing the certificate is far too difficult.
[snip]
That said, I will note that items 1,2,3,4 are arguably already in
scope for CURDLE.
To use RFC 5083 and RFC 5084, we need to do quite a bit more than just add
algorithms to a registry. In my opinion, we would need to produce S/MIME)
Version 3.3.
5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data
Content Type. R. Housley. November 2007. (Format: TXT=22810 bytes)
(Updates RFC3852) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC5083)
5084 Using AES-CCM and AES-GCM Authenticated Encryption in the
Cryptographic Message Syntax (CMS). R. Housley. November 2007.
(Format: TXT=21821 bytes) (Status: PROPOSED STANDARD) (DOI:
10.17487/RFC5084)
I am a big fan of doing (5). the point is to get people using end to
end encryption, not use one particular approach.
At least one person agrees. That is how it got on the list.
Russ
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime