Re: Amending the PKIX-WG Charter to reflect the addition of timestamping

[Russ Housley <housley@xxxxxxxxxx>]

It looks okay to me.....

At 07:17 PM 9/22/98 -0700, you wrote:
>Hi All, back in February we were working to amend the PKI WG's charter to
>encompass timestamping and the certified timer resources that enable these
>facilities. Now that Jeff Schiller has OK'd PKIX's having its own
>timestamping/timebase facility we need to finish the charter update process.
>here then is a proposed charter for your review and comments.
>
>Thanks,
>
>-----
>
>Todd Glassey
>
>Stephen Kent's report of the meeting minutes - excerpt below -
>
>- Timestamp & Notary proposals (Carlisle Adams)
>
>Several folks continuing work on these topics and have published an
>independent draft on
>these topics. The authors received a fair amount of private feedback, and
>hope to be able to
>bring forward a well-formed proposal. Jeff Schiller gave his permission to
>bring this into
>the WG, based on the WG having made substantial progress on the other work
>items. Thus
>we will expand the charter to encompass these topics.
>
>
>----- BEGINNING OF CHARTER TEXT ----
>
>Public-Key Infrastructure (X.509) (PKIX)
>--------------------------------------------------
>
> Charter
> Last Modified: September 18, 1998
>
> Current Status: Active Working Group
>
>Chair(s):
>Stephen Kent <kent@bbn.com>
>Warwick Ford <wford@verisign.com>
>
>Security Area Director(s):
>Jeffrey Schiller <jis@mit.edu>
>Marcus Leech <mleech@nortel.ca>
>
>Security Area Advisor:
>Jeffrey Schiller <jis@mit.edu>
>
>Mailing Lists:
>General Discussion:ietf-pkix@imc.org
>To Subscribe: ietf-pkix-request@imc.org
>In Body: subscribe (In Body)
>Archive: http://www.imc.org/ietf-pkix
>
>Description of Working Group:
>Many Internet protocols and applications which use the Internet employ
>public-key technology for security purposes and require a public-key
>infrastructure (PKI) to securely manage public keys for widely-distributed
>users or systems.  The X.509 standard constitutes a widely-accepted basis
>for such
>an infrastructure, defining data formats and procedures related to
>distribution
>of public keys via certificates digitally signed by certification
>authorities
>(CAs).
>
>For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
>primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).
>Since RFC 1422 was issued, application requirements for an Internet PKI have
>broadened tremendously, and the capabilities of X.509 have advanced with the
>development of standards defining the X.509 version 3 certificate and
>version 2 certificate revocation list (CRL).
>
>Charter of the Working Group:
>The charter of the working group will be to develop Internet standards
>needed to support the use of an X.509-based PKI.  The goal of this Working
>Group (WG)
>will be to further facilitate the use of X.509 certificates in applications
>that
>make use of the Internet and to promote interoperability between different
>implementations choosing to make use of X.509 certificates.
>
>The resulting PKI is intended to provide a framework, which will support a
>range of trust/hierarchy environments and a range of usage environments
>(RFC1422
>is an example of one such model).
>
>Candidate applications to be served by this PKI include, but are not limited
>to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet
>payment protocols, time based authentication, timestamping, and www
>protocols.
>
>This project will not preclude use of non-infrastructure public-key
>distribution techniques nor of non-X.509 PKIs by such applications.  Efforts
>will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
>project.
>
>The group will focus on tailoring and profiling the features available in
>the v3 X.509 certificate to best match the requirements and characteristics
>of the
>Internet environment.
>
>Other topics to be addressed potentially include:
>
>     * Alternatives for CA-to-CA certification links and structures,
>including
>       guidelines for constraints
>
>     * Revocation alternatives, including profiling of X.509 v2 CRL
>extensions
>     * Certificate and CRL distribution options (X.500-based,
>non-X.500-based)
>     * Guidelines for policy definition and registration
>     * Administrative protocols and procedures, including certificate
>       generation, revocation notification, cross-certification, and
>key-pair
>       updating
>     * Naming and name forms (how entities are identified, e.g., email
>       address, URN, DN, misc.)
>     * Generation of client key pairs by the PKI
>     * Services that support non-repudiation.  This can include sources of
>       credible time data and/or certificate path validation services.
>
>----- END OF CHARTER TEXT ----
>