draft minutes, again

[Stephen Kent <[e-mail]>]

Folks,

Whoops! I sent out a version of the minutes that did not refelect several
edits that I had alreday made. The version below is the one I would like to
have reviewed.

Sorry,

Steve
------------------------------------------------------

		    PKIX WG Meeting 12/8/98 & 12/9/98

			DRAFT MINUTES 2nd CUT

The PKIX WG met twice during the 43rd IETF and a approximately 190
individuals participated in  these meetings.

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX Cert/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt)
Approved for Proposed Standard

KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt)
In WG Chairs' hands - ready for publication as Informational RFC

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
In WG Chairs' hands - ready for WG Last Call

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)
In Editor's hands

LDAP V2 Operational Protocols
Awaiting scheme document and will be reviewed by IESG toghether.

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt)
In Area Director's hands, will be forwarded to IESG very soon.

OCSP (draft-ietf-pkix-ocsp-05.txt)
In Area Director's hands

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt)
About to be approved by IESG

CMC (draft-ietf-pkix-cmc-02.txt)
Under development.

CMMF (draft-ietf-pkix-cmmf-02.txt)
In WG last call, but probably will be deleted, due to subsumption by CMC.

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt)
In Area Director's hands (pending publication as Informational RFC)


Reports on Established Projects:

OCSP (A. Malparni-ValiCert)
Announcement of an OCSP server available for interoperability testing.

CMC (J. Weinstein-Netscape)
Notable changes from last time, and new text makes explicit what requirements
are being met. Given the extent of these changes, this I-D is NOT yet in WG
last call. CMC is primarily based on PKCS 10, and CMRF, and CMS (PKCS 7
successor developed in S/MIME). Protocol is stateless, to make life easier for
the server, optional for client. Features supported include client or CA
generation of key pairs, optional key recovery, POP, realtime and staged
delivery responses, and (local) RAs. Mandatory algorithms include DSA and D-H,
with RSA as an option. Steve Kent, WG co-chair, asked that the document be
revised to make explicit the security requirements imposed on CMC transactions
and whether these requirements are met by CMC in all cases, or whether CMC
optionally satisfies these requirements.  In the latter case, there are
security dependencies relative to the underlying protocol employed for
transport. Such dependencies must be explicitly stated in the document. Jeff
agreed to make the edits necessary to satisfy these concerns.

Carlisle Adams raised some concerns about the POP mechanisms contained in the
protocol and raised issues about the need for more details, and some edits
(e.g., OID values), to ensure interoperability.  Carlislie was asked to send
these issues to the list so that the CMC authors can address them prior to WG
last call.

Diffie-Hellman POP Mechanisms (J. Schad-Netscape)
Jim provided an update on an informational document that will specify a means
of proof of possession with non-fixed groups, consistent with S/MIME contexts.


PKIX Roadmap (A. Arsenault-NSA)
Al has received a few comments but is looking for more, and will continue to
refine the document as the last of the mainline

X.509 PDAM Update (T. Polk- NIST)
Tim presented several slides provided by Sharon Boyen (Entrust), describing
X.509 proposed changes from the September ITU-T meeting. The PDAM describes
new extensions related to attribute certificate revocation, etc.  Comments are
requested from PKIX WG members. For more details, see the message to the WG
from Hoyt Kesterson ([e-mail]), dated 11/23/98.


Reports on New(er) Topics:

Qualified Certificates (draft-ietf-santesson-qc-01.txt) (S. Santesson)
This I-D addresses profiling X.509 certificates for use in a particular
application context, i.e., for generation of digital signatures that will be
recognized as legal throughout the EU. These certificates are to be issued to
individuals who will generate digital signatures that support
non-repudiation.
There is an assumption that these certificates will be used not only with
custom applications, but also with standard IETF applications such as S/MIME,
hence the relevance to this WG. Only four certificate fields are addressed by
this: Issuer, Subject, Policy, and Key usage.  Thus a primary focus of this
document is on naming, both requiring support for specific DN attributes and
specifying semantics for the names. The slides provide additional details.

ETSI Report on Electronic Signature (D. Pinkas)
Denis provided a brief report on "electronic" signature standardization. This
is quite analogous to the previous presentation, with the further focus on
signatures for high value transactions. Again, non-repudiation is essential,
but here roles, not just individual identities, are relevant, as is the
context in which the signature is applied, e.g., as indicated by policy. The
ETSI group has identified a list of issues to be resolved in order to provide
the necessary framework for such high value signature applications. See the
slides for the URL and additional details.


Timestamp (draft-ietf-pkix-time-stamp-00.txt)
Data Certification Server (draft-ietf-pkix-dcs-00.txt) C. Adams- Entrust
Carlisle reviewed differences between the current drafts and the drafts
reviewed at the previous IETF meeting.  In particular, the new version of the
timed stamp I-D offers finer granularity for time stamps and support for time
stamping of just a nonce. It was suggested that we combine the services of
time stamping and document "notarization" into a single protocol, where the
object submitted could be a hash or the object itself. However, there was not
agreement that such combination was beneficial in all cases, and a single
server may offer both timestamping and data certification services with only
slightly greater complexity.  The CMP-derived status indications need to be
"masked" to clarify the fact that some CMP error conditions are not relevant
to this application.

The timestamp I-D appears to be ready to move to WG last call with the next
version, however the data certification I-D needs more work.  Also, the WG
chairs need to co-ordinate with the Security AD to modify the charter to
encompass both of these I-Ds.