Re: [lamps] DRAFT LAMPS Recharter Text

I think it makes sense to do byte sized pieces of work to make sure we get 'em done.   Let's focus on the two listed(I.e., remember the limited part of our charter and then circle back.

spt

Sent from my iPhone

> On Aug 17, 2017, at 07:40, Russ Housley <housley@vigilsec.com> wrote:
> 
> I have seen people voice support for the two work items listed in the draft charter text.  I have seen Max and Dmitry offer additional work items, but there has been almost no discussion of their suggestions.  Without active support, the suggested items will not be added.
> 
> Russ
> 
> 
>> On Aug 6, 2017, at 12:51 PM, Russ Housley <housley@vigilsec.com> wrote:
>> 
>> At IETF 99, the LAMPS WG considered several potential recharter work items.  The attached draft is a result of that discussion.  Please review and comment.
>> 
>> Russ
>> 
>> = = = = = = = =
>> 
>> The PKIX and S/MIME Working Groups have been closed for some time. Some
>> updates have been proposed to the X.509 certificate documents produced 
>> by the PKIX Working Group and the electronic mail security documents 
>> produced by the S/MIME Working Group.
>> 
>> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working 
>> Group is chartered to make updates where there is a known constituency 
>> interested in real deployment and there is at least one sufficiently 
>> well specified approach to the update so that the working group can 
>> sensibly evaluate whether to adopt a proposal.
>> 
>> Having completed the S/MIME 4.0 specifications and updates to support
>> i18n email addresses in PKIX certificates, the LAMPS WG is now:
>> 
>> 1. Specify a discovery mechanism for CAA records to replace the one
>> described in RFC 6844.
>> 
>> 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
>> 
>> RFC 6844 describes the mechanism by which CAA records relating to a
>> domain are discovered.  Implementation experience has demonstrated an
>> ambiguity in the current processing of CNAME and DNAME records during
>> discovery.  Subsequent discussion has suggested that a different
>> discovery approach would resolve limitations inherent in the current
>> approach.
>> 
>> Unlike the previous hashing standards, the SHA-3 functions are the
>> outcome of an open competition.  They have a clear design rationale and
>> have received a lot of public analysis, resulting in great confidence
>> that the SHA-3 family of functions are very secure.  Also, since the
>> design of the SHA-3 functions use a very different construction from the
>> SHA-2 functions, they offer an excellent alternative to the SHA-2 family
>> of functions.  In particular, SHAKE128/256 and SHAKE256/512 offer
>> security and performance benefits.
>> 
>> In addition, the LAMPS Working Group may investigate other updates to 
>> the documents produced by the PKIX and S/MIME Working Groups, but the 
>> LAMPS Working Group shall not adopt any of these potential work items 
>> without rechartering.
>> 
>> MILESTONES
>> 
>> Nov 2017: Adopt a draft for rfc6844bis
>> Dec 2017: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512
>> Dec 2017: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512
>> Apr 2018: rfc6844bis sent to IESG for standards track publication
>> Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for
>>           standards track publication
>> Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
>>           standards track publication
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm