Re: [lamps] DRAFT LAMPS Recharter Text

["Dr. Pala" <[e-mail]>]

Hi Russ, all,

I just added my additions to the charter and the related 
milestones.Please let me know what you think :D

Cheers,
Max

On 8/6/17 10:51 AM, Russ Housley 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.
3. Specify how to effectively reduce the size and increase the 
availability of
    revocation informationby leveraging DNS as a transport protocol.
> 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.
One of the major issues still open in PKIX is the efficient distribution of
revocation information. Because of this, the use of short-lived certificates
is seenas the only practical deployment solution in many environments.
The use of DNS as an alternative transport protocol and the reducing of the
size of revocation information via lightweight revocation tokens will 
improve
the overall adoption of best-practices for revocation checking, lower 
the costs
of revocation information distribution, and allow for distributed lookup
and caching capabilities.
> 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
Nov 2017: Adopt OCSP over DNS draft
> 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
Mar 2018: Adopt a draft for Lightweight Revocation Tokens
> Apr 2018: rfc6844bis sent to IESG for standards track publication
Apr 2018: OCSP-over-DNS 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
Sep 2018: Lightweight Revocation Tokens sent to IESG for standards
           track publication