Subject: [lamps] DRAFT LAMPS Recharter Text

From: Russ Housley <[email-masked]>
Date: Sun, 6 Aug 2017 12:51:24 -0400

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Aug 2017 14:00:49 +0000

LGTM although the dates seem the usual IETF optimistic :)

Can add a recharter item to get the mailing list moved/renamed?

---

From: Sean Leonard <[email-masked]>
Date: Mon, 7 Aug 2017 08:09:28 -0700

Reviewed.

Comment: looks good.

Sean

On 8/6/2017 9:51 AM, Russ Housley wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Sean Leonard <[email-masked]>
Date: Mon, 7 Aug 2017 08:10:13 -0700

> Can add a recharter item to get the mailing list moved/renamed?

I also agree about getting the mailing list moved/renamed.

Sean

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Aug 2017 17:00:26 -0400

> I also agree about getting the mailing list moved/renamed.

This does not have anything to do with the charter.

The previous AD felt that changing the name of the mail list was not important.  I do not know what the new AD thinks.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Aug 2017 21:04:59 +0000

> This does not have anything to do with the charter.

Hence the initial smiley.

> The previous AD felt that changing the name of the mail list was not important.  I do not know what the new AD thinks.

If we changed the name because of sensitivity issues then we should change the mailing list name because, in the IETF, WG's die but mailing lists never do.  And if there were other reasons, having the WG name and email name different is jarring.

Of course you know this :)

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Aug 2017 00:58:53 +0300

> On 8 Aug 2017, at 0:04, Salz, Rich <[email-masked]> wrote:
> 

Perhaps, but changing the group name is just a little administrative work. Changing the mailing list is disruptive. What happens if a message is sent tot spasm@?  If it gets delivered, we haven’t really changed the name, just created an alias. If it causes a reject, it causes a disruption (and not the good kind) to all participants.

On the bright side only a few mailing lists are really forever. Years from now, when lamps and curdle have closed, nobody is going to use these lists. They will still use [email-masked] <mailto:[email-masked]>, but not these two.  It’s the same way that if anyone wants to talk about web security at the IETF, they’re going to SAAG, not websec@ and not httpauth@.  I should know. These lists have been dead since the respective working groups have closed.

Yoav

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 14 Aug 2017 17:12:47 +0300

Hello,

On Sun, Aug 6, 2017 at 7:51 PM, Russ Housley <[email-masked]> 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
>
> = = = = = = = =
>

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Aug 2017 08:40:27 -0400

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 <[email-masked]> wrote:
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 18 Aug 2017 09:02:35 -0500

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 <[email-masked]> wrote:
>

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 24 Aug 2017 12:31:21 -0600

Hi Russ, all,

I am sorry I was not able to send in the items right away - I think 
there has been some e-mails about supporting the work we are proposing, 
in particular adding a work item related to revocation. When you say 
"active support" what does that actually mean ? I think we demonstrated 
interest around the specific topic (there have been several messages 
across the different mailing lists - i.e., pkix, lamps, and saag).

However, we still need the charter and milestones for the proposed work 
to see if we can adopt it in this WG. I will send in the charter text 
and milestones soon.. sorry again for the delay, but I hope the items 
will be considered for the charter :)

Cheers,
Max

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 24 Aug 2017 13:06:34 -0600

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

> 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.
3. Specify how to effectively reduce the size and increase the 
availability of
    revocation informationby leveraging DNS as a transport protocol.
> 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.
> Nov 2017: Adopt a draft for rfc6844bis
Nov 2017: Adopt OCSP over DNS draft
> 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
>               standards track publication
Sep 2018: Lightweight Revocation Tokens sent to IESG for standards
           track publication

---

From: Russ Housley <[email-masked]>
Date: Mon, 28 Aug 2017 10:07:57 -0400

For the current items, "active support" meant that more than one party was willing to implement the RFC produced by the group.

Russ

> On Aug 24, 2017, at 2:31 PM, Dr. Pala <[email-masked]> wrote:
> 
> Hi Russ, all,
> 
> I am sorry I was not able to send in the items right away - I think there has been some e-mails about supporting the work we are proposing, in particular adding a work item related to revocation. When you say "active support" what does that actually mean ? I think we demonstrated interest around the specific topic (there have been several messages across the different mailing lists - i.e., pkix, lamps, and saag).
> 
> However, we still need the charter and milestones for the proposed work to see if we can adopt it in this WG. I will send in the charter text and milestones soon.. sorry again for the delay, but I hope the items will be considered for the charter :)
> 
> Cheers,
> Max
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Aug 2017 14:54:31 +0000

OpenSSL is interested.

On 8/28/17, 10:07 AM, "Russ Housley" <[email-masked]> wrote:

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 28 Aug 2017 18:02:22 +0300

Do you mean Dr.Pala's suggestion or mine one? They are related in some way,
but not equivalent.

Thank you!

On Mon, Aug 28, 2017 at 5:54 PM, Salz, Rich <[email-masked]> wrote:

>     For the current items, "active support" meant that more than one party
> was willing to implement the RFC produced by the group.
>
>

-- 
SY, Dmitry Belyavsky

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Aug 2017 15:03:20 +0000

We are interested in both things.

That is of course, not a promise to commit, but there is definite interest.

---

From: Russ Housley <[email-masked]>
Date: Mon, 28 Aug 2017 11:14:04 -0400

This definition applies to all work that will be considered by the LAMPS WG.  As I said, this is the definition that was used for the current items, and it will be used for any new topics as well.

Russ

> On Aug 28, 2017, at 11:02 AM, Dmitry Belyavsky <[email-masked]> wrote:
> 
> Do you mean Dr.Pala's suggestion or mine one? They are related in some way, but not equivalent.
> 
> Thank you!
> 
> On Mon, Aug 28, 2017 at 5:54 PM, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
> OpenSSL is interested.
> 
> On 8/28/17, 10:07 AM, "Russ Housley" <[email-masked] <mailto:[email-masked]>> wrote:
>