Fwd: Re: [Curdle] WG Action: Formed CURves, Deprecating and a Little more Encryption (curdle)

[Stephen Farrell <[e-mail]>]

Sorry - forgot to forward this here. The curdle WG that
is planned to handle a few ssh algorithm issues has been
formed. Please join that list if you're interested in
those drafts (mainly [6] and [7] below I guess).

Cheers,
S.


-------- Forwarded Message --------
Subject: Re: [Curdle] WG Action: Formed CURves, Deprecating and a Little
more Encryption (curdle)
Date: Fri, 18 Dec 2015 16:56:57 +0000
From: Stephen Farrell <[e-mail]>
To: [e-mail]


Thanks all for the help with writing docs and the charter to
get this going.

And now off you go to get the work done!

Cheers,
S.

On 18/12/15 16:52, The IESG wrote:
> A new IETF working group has been formed in the Security Area. For
> additional information please contact the Area Directors or the WG
> Chairs.
> 
> CURves, Deprecating and a Little more Encryption (curdle)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>   Daniel Migault <[e-mail]>
>   Rich Salz <[e-mail]>
> 
> Assigned Area Director:
>   Stephen Farrell <[e-mail]>
> 
> Mailing list
>   Address: [e-mail]
>   To Subscribe: https://www.ietf.org/mailman/listinfo/curdle
>   Archive: https://mailarchive.ietf.org/arch/browse/curdle/
> 
> Charter:
> 
> CURDLE - CURves, Deprecating and a Little more Encryption
> 
> The CURDLE working group is chartered to add a small set of cryptographic
> mechanisms to some IETF protocols, and to make implementation
> requirements including deprecation of old algorithms where there is IETF
> consensus to do so. The focus with regards to adding mechanisms is for
> those mechanisms that enjoy broad support from implementers.
> 
> The set of cryptographic mechanisms that can be introduced are limited to
> key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and
> Curve448 as defined by CFRG [1] [2], and the AEAD mode ciphers consisting
> of ChaCha20 and Poly1305 also defined by CFRG [3]. Other variants of
> mechanisms, such as the ChaCha20-Poly1305 construct deployed for SSH, may
> also be considered as well as AES-CCM[4] and AES-GCM [5] where those are
> not already defined and where there is implementer interest.  Related
> specifications such as private and public key formats are also within
> scope.
> 
> The protocols the WG intends to work on are Secure Shell (SSH), DNSSEC,
> PKIX, CMS, XML Digital Signatures and potentially XML Encryption,
> Kerberos and JSON.
> 
> Where initial drafts for this work have been produced those will be
> immediately considered for adoption as working group documents.  These
> include, for SSH, Curve25519/Curve448 digital signatures [6] and key
> exchange [7]; for DNSSEC, Ed25519 [8] and Curve448 [9]; for PKIX,
> Curve25519/448 NamedCurve [10] and EdDSA signatures [11]; for JSON curves
> and signatures [12].
> 
> The CURDLE working group will be handling changes to protocols and
> registries some of which include what are now considered outdated
> algorithm options, and may propose deprecation of such algorithms. Such
> deprecation needs to be done with care, ensuring that interoperability
> and the needs of existing implementers and deployments are properly
> considered. Where deprecation is practical, the working group is
> encouraged to deprecate.
> 
> Where there is an IETF working group or area group with expertise in a
> relevant topic the CURDLE working group will defer to the consensus of
> the more specific  working group as to where work will be done. For
> example, the TLS, OpenPGP and IPSECME WGs are actively considering some
> of these topics.
> 
> The CURDLE working group will liaise with W3C to ensure that XML digital
> signature and XML encryption work does not conflict with W3C.
> 
> The CURDLE working group is expected to be a short-lived working group
> that may not need to ever meet face-to-face. Once the work on the
> initially adopted set of drafts has completed the working group will
> close or re-charter.
> 
> The CURDLE working group is not chartered to consider allocating new
> codepoints for any algorithms or modes other than those mentioned above. 
> Should someone wish to propose such work, a re-charter will be required.
> At this time, there is no expectation that such a re-charter  will be
> requested.
> 
> [1] https://tools.ietf.org/html/draft-irtf-cfrg-curves
> [2] https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00
> [3] RFC 7539
> [4] RFC 3610
> [5] RFC5288
> [6] https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02
> [7] https://tools.ietf.org/html/draft-josefsson-ssh-curves-00
> [8] https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03
> [9] https://tools.ietf.org/html/draft-sury-dnskey-ed448-00
> [10] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01
> [11] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04
> [12] http://www.ietf.org/mail-archive/web/jose/current/msg05357.html
> 
> 
> Milestones:
>   Jan 2016 - Decision on which drafts to adopt
>   Jun 2016 - Send last draft to IESG
> 
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
> 

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