Limited Additional Mechanisms for PKIX and SMIME

Note: This ballot was opened for revision 01-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

(Kathleen Moriarty) Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Alissa Cooper No Objection

Spencer Dawkins No Objection

Comment (2018-02-07 for -01-00)
No email
send info
Nice work on this one.

This is very nit-picky, but perhaps placing the explanation of each topic immediately following the list item naming the topic would be clearer? 

Like, so:

Having completed the S/MIME 4.0 specifications and updates to support
i18n email addresses in PKIX certificates, the LAMPS WG is now tackling
these topics:

1. Specify a discovery mechanism for CAA records to replace the one
   described in RFC 6844.

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

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and

Unlike the previous hashing standards, the SHA-3 family of functions are
the outcome of an open competition.  They have a clear design rationale
and have received a lot of public analysis, which gives great confidence
that the SHA-3 family of functions are secure.  Also, since SHA-3 uses a
very different construction from SHA-2, the SHA-3 family of functions
offers an excellent alternative.  In particular, SHAKE128/256 and
SHAKE256/512 offer security and performance benefits.

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Alexey Melnikov No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-02-07 for -01-00)
No email
send info
It's probably a good idea to adjust the milestones so that they all have future dates on them.