[pkix] Identified Work Items and Discussion Summary (was: possible new pkix and/or smime work)

[Wei Chuang <[e-mail]>]

Hi all,

I've created a Google Docs of the potential work items and discussion
summary (associated with my personal email account).  This will make it
easy to take comments on the document and incorporate them into the
document easily.  The following link goes to the document:
https://goo.gl/xXbBoc (i.e.
https://docs.google.com/document/d/1bZ9BHiw1FvTj1HKEWlfUqe4811KroY_Ottzl3fye-eE/edit?usp=sharing
which might get split by some email clients)

Here's a link to the help center on how to make a comment in the docs:
https://support.google.com/docs/answer/65129?co=GENIE.
Platform%3DDesktop&hl=en

For those who prefer a text document, I've inlined it below.  Please use
the above Google Doc link, because it automates making changes to document.

thanks,
-Wei

----------

IETF PKIX / S/MIME Feb-Mar 2016
Work Items
Potential work list:


Short term:
1. EKU for intermediate CA certificate
2. Manufacturer Usage Description URI certificate extension
3. Certificate i18n email address support
4. Non authoritative key lookup (see bhjl draft)
5. Solving incomplete certificate chains and handing expired certificates
cleanly on clients
6. Adding new S/MIME crypto: AEAD: AES-CCB, AES-GCM,
AES-CCChaCha20-Poly1305, CRFG ECC Curves
7. Deprecate old ciphers e.g. md5, sha1
8. Support for PGP keys in CMS
9. Update RFC4134 i.e. S/MIME examples
10. drafts
   1. draft-lear-ietf-pkix-mud-extension-00
   2. draft-lbaudoin-iemax-02
   3. draft-ietf-pkix-eai-addresses-00
   4. draft-bhjl-x509-srv-00
   5. Draft-melnikov-smime-msa-to-mda-04


Long term
1. Certificate discovery and reenrollment
2. Solving email address canonicalization (perhaps via bhjl oracle)
3. Header privacy
4. Prevent signature stripping attack
5. Painless client configuration


Even longer term
1. Supporting Webmail
2. Preventing Spam
3. Combining PGP S/MIME
4. Email identity


________________


Opinions


PKIX Mailing List


Strings in certificates: Want clarifications in 5280 regarding strings
* Date: 18 Jan 16
* Issue: Deprecating types; interpretation for DisplayText; Unicode
normalization; Control Characters; Unicode for rfc882Name
* Discussion: See X.520 and other documentation


EKU for intermediate certificates: Allow EKU in intermediate CA cert to
allow technical constraints as specified by CABF
* Start: 4 Feb 16
* Issue: Worry significant change since EKU wasn’t meant to impact path
validation; Implementers haven’t been following path constraints very well;
Interoperability challenge due to different standards
* Proposal: New extension; New interpretation; Follow policy OID; other
answers in archive


Is it time for a pkix extensions (or similar) wg?
* Start: 5 Feb 16
* Proposals: Manufacturer cert extension (see lear draft); i18n for cert
rfc822Name (see lbaudoin, eai-addresses drafts) spawned address discussion
noted below; S/MIME name matching selector in SignerInfo: case,
normalization?  What about S/MIME WG (stephen farrell)?
* Issue: S/MIME: “biggest problem… how to tell senders what they should
do”; successor to S/MIME and PGP?; Enough work for two working group? Or
just one working group?
* Drafts:  draft-lear-ietf-pkix-mud-extension-00; draft-lbaudoin-iemax-02;
draft-ietf-pkix-eai-addresses-00.txt


Email address matching rules (was Re: Is it time for a pkix extensions (or
similar) wg?)
* Start: 6 Feb 16
* Issue: email address local part normalization is against RFC5321; Sec 7
of RFC5280 needs updating; Security model
* Proposal: Sender should normalize (see 5750); define rules in DKIM or
DNS; define OTHER-NAME in cert SAN/IAN in UTF8String with encoding of
matching rules; Regex SAN/IAN; Formalize security model; Sender does cert
lookup to find alternate address variant certificate;
* Note: large discussion by SMTP folks noted below in: Another attempt to
canonicalize local parts
* Drafts: draft-bhjl-x509-srv-00


Support for email address internationalization in RFC5280 certificates
* Start: 4 Feb 16
* Draft: draft-lbaudoin-iemax-02.txt (see also
draft-ietf-pkix-eai-addresses-00)
* Counter proposal: Consider instead redefining Rfc822Name as CHOICE
including UTF8String


key identities
* Start: 14 Mar 16 (from tmiller on: why you shouldn't even try to
canonicalize local parts)
* Proposal: Verify signature and cert path, TOFU the address FROM/SENDER
address and remember public key;  identify by public key SKID, subsequently
only verify the signature from the public key; Key roll over
* Issue: signing?; a priori discovery?; human comprehensible notion of
identity or name


Summary of S/MIME Problems/Issues
* Start: 11 Mar 16 (from mrex on: another attempt to canonicalize local
parts)
* Issues: Incomplete chains; Mail archival problems when certificates
expire i.e. revalidating signature or decryption due to MUA certificate and
timestamp management, and lack of help from CAs


Another attempt to canonicalize local parts: 3rd party interpretation of
email address local parts for validation or key discovery  is a bad idea
* Start: 11 Mar 16
* Issues: RFC5321 stats only MTA may interpret the local part; MUA UI
poorly does key management; “key structures” i.e. key discovery is difficult
* Proposal: Modernize email address to enable validation; IETF should get
into standardizing UI particularly for key management; Key discovery via
oracle


e2e email security (stephen farrell)
* Start: 12 Mar 16
* Issues: No MUA development; email environment is centralized; mail
headers not protected; e2e may prevent anti-spam technology
* Proposal: allow experimentation


Key lookup service via draft-bhjl-x509-srv-00
* Start 22 Mar 16
* Proposal: Use the draft for key lookup; provides means to do initial
certificate discovery; authoritative; certificate renewal; oracle for new
email name variants;
* Issues: Key management is hard; security risk for automated key
re-enrollment; security issues with a centralized key directory; handling
ownership of multiple mailbox;
* Draft: draft-bhjl-x509-srv-00


BCP proposal: regular expressions for Internet Mail identifiers
* Start: 22 Mar 16
* Proposal: Standardize regex for email addresses


S/MIME Mailing List


Message takeover attacks against S/MIME
* Start: 27 Jan 16
* Proposal: Adding authenticated encryption to S/MIME;
* Issues: S/MIME doesn’t keep headers private; MUA don’t understand
message/rfc822; attack via signed-then-encrypted message into
encrypted-then-signed using attackers identity and replies will leak the
original content


Is this enough to re-charter the S/MIME WG?
* Start: 8 Mar 16 (from housley on “Message takeover attacks against
S/MIME”)
* several folks willing to help; AEAD: AES-CCM, AES-GCM, ChaCha20-Poly1305;
domain signing; Curve25519 and Curve448, CFRG ECC curves;  automated cert
enrollment; protect mail headers; standardize on RFC5753  i.e.ECC away from
informational; updated RFC documentation e.g. RFC 4134; drop old ciphers
e.g. md5, sha1; prevent signature stripping attacks
* Draft: draft-melnikov-smime-msa-to-mda-04


General S/MIME issues / solutions
* Start: 29 Jan 16 (from phill on: Message takeover attacks against S/MIME)
* Proposal: merge PGP and S/MIME; publish consistent modern crypto suit in
CURDLE; make it work with WebMail; configuration must be painless


---------- Forwarded message ----------
From: Stephen Farrell <[e-mail]>
Date: Thu, Mar 24, 2016 at 5:28 AM
Subject: Re: [pkix] possible new pkix and/or smime work
To: pkix <[e-mail]>



I got a couple of volunteers, Wei Chuang and John Levine
(thanks both!) who're aiming to produce us a summary of
the recent list discussion we can ponder in a few days.

Cheers,
S.

On 23/03/16 20:35, Stephen Farrell wrote:
>
> Folks,
>
> I'm finding it hard to evaluate the discussion as to whether
> there's new work folks want to do here that'd justify forming
> a (coherent) WG and that'd result in likely implementation and
> deployment. I expect others may be similarly uncertain.
>
> Would someone be willing to volunteer to act in a slightly
> chair-like manner and try to summarise the discussion in a
> way that might help us judge the above?
>
> I think that might help us to e.g. organise a bit of a bar
> BoF or collective chat amongst those interested while a bunch
> of us are in B-A and on the list prior to that.
>
> Thanks,
> S.
>
> PS; If you are willing to do that but shy, feel free to send to
> me offlist and I can pretend I did the work:-)
>
>
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>


_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix