Re: [lamps] DRAFT LAMPS Recharter Text

[Dmitry Belyavsky <[e-mail]>]

Hello,

On Sun, Aug 6, 2017 at 7:51 PM, Russ Housley <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>

I suggest to add one more item to the charter:

===============
3. Specify a mechanism/language describing the application-level
limitations to certificate trust.

There are a lot of limitations applied to the trust model specified by the
RFC 5280 by browsers,
see for example
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/--aa6dYHhrc/xbozEdS2BgAJ
This limitations distributed in well-documented alienable format can be
used by various applications,
such as MTAs and browsers, and improve the overall security of PKI
infrastracture.
================

Thank you!

-- 
SY, Dmitry Belyavsky