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

[Stephen Farrell <[e-mail]>]

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 <[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
>