PKIX WG Minutes, final

[Stephen Kent <[e-mail]>]

Here is the final version of the minutes, edited to reflect comments from
several folks over the last 2 weeks.

Happy Holidays,

Steve

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


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

Edited by Steve Kent (WG co-chair)

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-11.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 Editors' hands.

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)
In WG Chairs'/Area Director's hands - ready for IESG

LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)
Awaiting schema document and will be reviewed by IESG together.

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

OCSP (draft-ietf-pkix-ocsp-07.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 - ready for publication as Informational RFC

Reports on Established Projects:

OCSP (A. Malpani-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. Schaad-Microsoft)
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. There was general agreement that the result of this work will be
appropriate as a standards track (vs. informational) RFC.


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 Standardization (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 additional details. The report is available at:
http://www.etsi.org/SEC/ESRep042.pdf


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.