Thanks for doing that.
What I'm most interested in for now is who would implement and/or
deploy which bits of possible work. So if you can annotate Wei's
document with that kind of information or otherwise make that
clear on the list, that'd be very useful. (Please note that I am
much much more interested if someone says they'd implement,
compared to someone just expressing interest or wishing that
someone else would implement.)
And separately, I'd like to try get interested folks who'll be
at IETF95 together for a chat if we can. At the moment, either
Monday lunch or Thursday about 8pm (during bits'n'bytes) seem
like they'd work for me. If you'd come along please send a mail
to me, Wei and John Levine and we can see what's likely best.
(If you really like to be involved in that but are remote, do
say so. I'm not sure having many remote folks will work so well
for this kind of discussion but we can try if need be.)
Cheers,
S.
PS: I'll be travelling from tomorrow so offline a good bit,
but please keep the discussion going on the list.
On 31/03/16 19:59, Wei Chuang wrote:
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 <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Date: Thu, Mar 24, 2016 at 5:28 AM
Subject: Re: [pkix] possible new pkix and/or smime work
To: pkix <pkix(_at_)ietf(_dot_)org>
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
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime