[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Amending the PKIX-WG Charter to reflect the addition of timestamping
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 ----