Re: Proposed Charter Amendment...

[Russ Housley <housley@xxxxxxxxxx>]

Todd:

I do not agree.  In my view, the Introduction section of each
document should provide the necessary context for the rest of the
document.  If you do not believe that sufficient context is being
provide, then send comments to the list -- and offer some additional
text.  The debase on the list will determine if there is
concensus.

Russ


At 08:30 AM 09/11/2000 -0700, todd glassey wrote:
> Gentlefolk -
>  
> A year or so ago I brought up the concept that
> PKIX Standards and RFC's were different than many of the other standards
> that the IETF was producing in that many of them would be concerned with
> end-user processes and requirements. Because of this I am proposing
> (again) to set an additional requirement that ALL RFC's in PKIX that are
> to be advanced to STANDARDS have an associated Applicability Document
> (AD) and that no standard effort will be allowed to proceed past RFC
> without one. 
>  
> This  requirement is needed for a number
> of reasons not the least of them being that other standards orgs need to
> use this material as a basis of their efforts (the IETF being one of the
> lowest links on the Standard's Food Chain.
>  
> My belief is that this is critically true of a
> number of the efforts currently underway, like the TSP and OCSP protocol
> efforts. Anyway - the current charter is included below for reference as
> well as the proposed amendment to paragraph two.
>  
> ---------------------
>  
> The PKIX Working Group was established in the
> Fall of 1995 with the intent of developing Internet standards needed to
> support an X.509-based PKI. Several informational and standards track
> documents in support of the original goals of the WG have been approved
> by the IESG. The first of these standards, RFC 2459, profiles the X.509
> version 3 certificates and version 2 CRLs for use in the Internet. The
> Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate
> Status Protocol (OCSP) (RFC 2560), and the Certificate Management Request
> Format (CRMF) (RFC 2511) have been approved, as have profiles for the use
> of LDAP v2 for certificate and CRL storage (RFC 2587) and the use of FTP
> and HTTP for transport of PKI operations (RFC 2585). RFC 2527, an
> informational RFC on guidelines for certificate policies and practices
> also has been published, and the IESG has approved publication of an
> information RFC on use of KEA (RFC 2528) and is expected to do the same
> for ECDSA. Work continues on a second certificate management protocol,
> CMC, closely aligned with the PKCS publications and with the
> cryptographic message syntax (CMS) developed for S/MIME. A roadmap,
> providing a guide to the growing set of PKIX document, is also being
> developed as an informational RFC. 
>
> The working group is now embarking on additional standards work to
> develop protocols that are either integral to PKI management, or that are
> otherwise closely related to PKI use. Work is ongoing on alternative
> certificate revocation methods. There also is work defining conventions
> for certificate name forms and extension usage for "qualified
> certificates," certificates designed for use in (legally binding)
> non-repudiation contexts. Finally, work is underway on protocols for time
> stamping and data certification. These protocols are designed primarily
> to support non-repudiation, making use of certificates and CRLs, and are
> so tightly bound to PKI use that they warrant coverage under this working
> group. 
>
> Additional work will be initiated on a profile for X.509 attribute
> certificates, resulting in a new RFC and, perhaps, in extensions to
> existing certificate management standards to accommodate differences
> between attribute certificates and public-key certificates. 
>
> ---------------------------------
>
> Amended Text for Paragraph 2:
>
> The working group is now embarking on additional standards work to
> develop protocols that are either integral to PKI management, or that are
> otherwise closely related to PKI use. Many of these standards are
> directly tied to end use standards and where applicable, external input
> will be sought and factored into the efforts. 
>
> These projects currently include a number of ancillary efforts like:
> alternative certificate revocation methods; defining conventions for
> certificate name forms and extension usage for "qualified
> certificates"; certificates designed for use in (legally binding)
> non-repudiation contexts, and NON-REPUDIATION Services like time stamping
> and data certification.  Many of these protocols are designed
> primarily to support non-repudiation, making use of certificates and
> CRLs, and are so tightly bound to PKI and end-use models that their
> technology warrants coverage under this working group. 
>
>  
>
> --------------------------------