Subject: Proposed Charter Amendment...

From: "todd glassey" <[email-masked]>
Date: Mon, 11 Sep 2000 08:30:16 -0700

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. 

--------------------------------

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Sep 2000 13:34:09 -0400

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.

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.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Sep 2000 18:56:50 -0400

Todd,

>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 

Why would one declare this to be a requirement for PKIX documents, 
but not for all other IETF RFCs? It is the nature of many RFCs that 
they provide infrastructure elements upon which many different 
applications are built.  When TCP and IP were devised 25 years ago, 
there was no appreciation for the very wide range of applications 
that would be making use of these protocols today. If we're lucky, 
the same will be true of the PKIX RFCs.

>  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.

I'm sure this was meant as a compliment, said the co-chair of the 
bacteria standards committee :-).

>  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.

I think Russ's reply is accurate, i.e., each I-D contains an 
introduction section and we judge each document in terms of the 
adequacy of all of its parts.  I'm not saying that we could not do 
better, but I do not think a separate AD is required.

Your proposed rewording of the charter is consistent with your 
earlier message about wanting to transform our standards process to 
more directly support the use of PKI in various business models. But, 
that's not what we do. Again, I refer to the NR debates we have had 
and the distinction we chose to make between technical NR and legal 
NR, as detailed in Tom's document.

Steve