draft PKIX meeting minutes

[Stephen Kent <[e-mail]>]

Folks,

The following minutes are submitted for review.  Please respond to me 
with comments and corrections, no later than 11/26, so that I can 
submit the revised minutes to the IETF secretariat in a timely fashio.

Steve
----------


PKIX WG Meeting 11/9+10/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met twice during the 46th IETF and a total of 
approximately 285 individuals participated in these meetings over two 
days.

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 COMPLETED DOCUMENTS

PKIX Certificate/CRL Profile (RFC 2459)
		Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
		Approved as Informational RFC
HTTP/FTP Operations (RFC 2585)
		Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
		Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
		Approved as Proposed Standard
OCSP (RFC 2560)
		Approved as Proposed Standard
CMP (RFC 2510)
		Approved as Proposed Standard
CRMF (RFC 2511)
		Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
		Approved as Informational RFC
CMC
		In IETF last call
Diffie-Hellman Proof of Possesion
		In IETF last call


PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-00.txt)
	Work underway

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
	Completed Wg last call and ready to forwarded to IESG

Qualified Certificates (draft-ietf-pkix-qc-02.txt)

PKIX Roadmap (draft-ietf-pkix-roadmap-04.txt)

Time Stamp (draft-ietf-pkix-time-stamp-04.txt)

Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)

Attribute Certificate Profile for Authorization 
(draft-ietf-pkix-ac509prof-01.txt)

Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)

DCS (draft-ietf-pkix-dcs-03.txt)

Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-01.txt)

OCSP Extensions (draft-ietf-pkix-ocspx-00.txt)

CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)

CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)


X.509 (2000) STATUS (S. Boyen- Entrust)

FPDAM Copenhagen meeting update. Deadline for revisions to ITU-T/ISO 
is 11/20, in preparation for March 2000 ballot. 2000 version (but not 
1997 version), will adopt PKIX convention re basicConstraints. 1997 
and 2000 text will reflect PKIX definition of v2 CRLs (with no 
extensions). New extension: inhibitAnyPolicy. Several new LDAP schema 
object classes defined for PKI support. Defect reports for several 
items being processed now.  There will be a complete restructuring of 
the X.509 text, to improve it. Attribute certificate changes (v2) 
include removal of some overly complex features (cross domain and 
indirect delegation of privileges), and addition of object hash 
facilities, as a means of binding an AC to a PKC or a software 
module, etc. See slides for more details on this presentation.


REPORTS ON ESTABLISHED WORK ITEMS:


Revisions to RFC 2459 (T. Polk-NIST)
Most text unchanged from RFC; a number of typos were fixed. Major 
changes are new path certificate path and added CRL validation text. 
(Old text was incomplete, new version corrects several defects 
discovered and then fixed in ISO/ITU-T text.) Other significant 
changes include AIA extension clarifications and DisplayText changes, 
plus addition of new extension from X.509 (inhibitAnyPolicy). 
Question: can we progress to Draft, or must we cycle as Proposed? The 
WG Chairs will talk with the Security ADs re this issue. The list is 
requested to identify 2 independent implementations as part of 
progression to Draft status. Please respond to the WG Chairs re this 
issue. Tim will work to resolve an issue with regard to the proper 
OID to use with the DC attribute in DNs. (This is an issue because 
another IETF WG defined this OID, but didn't register it properly.) A 
suggestion was made to keep ECDSA document (WG last call done) 
separate. A suggestion was made to add text to clarify the use of the 
NR bit, but most of the discussion was deferred to the more general 
NR topic at the end of the agenda.

CA Key Compromise Recovery (D. Pinkas) Both Germany and Italy, in 
digital signature regulations, require some for of ancillary time 
stamping of certificates to provide a transition interval for 
transition to newly issued certificates for users of the CA whose key 
was compromised. Adoption of these sorts of techniques would require 
extension of the path validation algorithm to process these time 
stamps, when there was an indication of CA key compromise.  (This 
indication could be provided by having the CA revoke its self-signed 
certificate in a CRL that is signed using a separate CA key, or via 
OCSP responses signed using a separate key.) It is noted that this 
mechanism addresses the problem of the compromise of one key (a CA 
key) by adding a second signature (for a time stamp) under a separate 
key. It also is possible for a CA to use key splitting and thus 
achieve the same effect in a transparent fashion. It also was 
suggested that one could add an extension that is an independent 
signature of the PublicKeyInfo (and SubjectName?) fields, to achieve 
the same effect. See slides for more details on this presentation.

Qualified Certificates (S. Santesson)
Since Oslo meeting conducted WG last call, and as a result of the 
comments received, a new ID was published on 10/22.  Changes include 
fixes to some ASN.1 syntax, inclusion of two new Subject attributes 
(pseudonym and title), plus a qcStatements extension.  Ongoing 
discussion focuses on several topics: can two QCs be compared to 
determine whether the same person is represented (reword to warn 
about such comparisons, but don't prohibit them), inclusion of a 
static identifier (use dnQualifier), use of ISO 3166 trigraphs vs. 
digraphs (use digraphs), and a restructuring of the personal data 
field attributes (done). So, time for WG last call, on this revised 
ID. RFC 2459 will be modified to recommend (SHOULD) support for the 
pseudonym attribute. See slides for more details on this presentation.

OCSP Extensions (P. Baker-VeriSign)
Original protocol focuses on validation of one certificate, returns a 
signed response to a client for later use in NR, and allows for a 
per-use charging model. This proposal to extend OCSP to support path 
processing, while maintaining most of the syntactic basis of OCSP. It 
is noted that delegation of path processing does not necessarily 
indicate delegation of trust, if the protocol returns the data needed 
to verify what the server did to determine certificate validity. Note 
that certificate policy processing is target dependent, so offloading 
path validation requires that the client must pass data to the 
server, to parameterize validation, e.g., a URI. (Note that this 
reveals more info to the server that would be necessary if the client 
merely passed parameters that would have been sent across an API for 
local path processing.)  Ultimately, this presentation proposes using 
OCSPX as the protocol for interacting with an authorization server, 
and that one can use the returned tokens as part of an audit trail.

Audience questions/comments: in what contexts might this be used vs. 
existing standard protocols (e.g., TLS, IPsec, etc.), whether the 
OCSP syntax is suitable for this application (OCSP does not pass full 
certificates), how attribute certificates fit in, two expressions of 
support for path construction and validation but not necessarily 
authorization.

PKIX Roadmap (S. Turner-IECSA)
Two updates since last meeting, focus on attribute certificates and 
non-repudiation. More text will be added for trust models, DCVS, POP, 
etc.

Time Stamping Protocol (D. Pinkas-Bull)
Denis discussed the differences between version 2 and version 4. 
Major changes include: A time stamp format based on GeneralizedTime 
(which allows sub-second time) and an optional field that specifies 
the accuracy of the first field is now employed. The serial number is 
now mandatory, allowing unique identification of a timestamp from a 
TSA. TDA extensions have been removed, but a facility for extensions 
has been retained. TSAs no longer explicitly assert anything about 
the hash function being used. The format of the TSTInfo has changed, 
and is now simpler. From a legal standpoint, there is better reason 
to believe that we can now proceed with this work without 
encountering significant intellectual property issues. The patent 
infringement case filed by Surety against Entrust resulted in the 
first four claims of the (most general) Surety patent being declared 
invalid.  These claims covered the basic notions of time stamping as 
we perform it in the TSP.  Other patent claims may still be 
applicable to implementations of a "secure" TSA clock, or the way the 
time stamp is employed.  For example there is a patent on secure 
hardware implementation of a time stamp time source, and on the use 
of a time stamp to extent the lifetime of a certificate. The basic 
protocol patent issues seem to be resolved at this time, at least in 
the US patent system. See slides for more details on this 
presentation.

LDAPv3 Profile (D. Chadwick- University of Salford)
No presentation. Need to check on status of document re WG last call.

Attribute Certificates	(S. Farrell-SSE)
Latest version moved LAAP to a separate draft, removed concept of 
"restrictions," added new AC revocation options (e.g., "never revoke" 
for short-lived certificates) and adds support of linking to owner 
via a hash value (currently just a link to a public key, but could be 
broadened to be more general). The new version is simplified and all 
parts are mandatory to implement. Several syntax changes were made, 
to help manage creation of new extension. More syntax changes will be 
required to align with v2 X.509 ACs. Plan is to create a 03 version 
before the March IETF and progress to WG last call around that time. 
See slides for more details on this presentation.

A new protocol (LAAP) for AC acquisition is defined here.  It is 
currently encapsulated in CMP PKIMessage syntax. It is not a 
replacement for LDAP, but an alternative when one choose not to store 
ACs in a directory. The protocol is quite limited in scope, e.g., 
fetches just one AC. It is not designed to be a management protocol 
for ACs (could extend CMP/CMC for that purpose).  Fetches are keyed 
using strings, either matched against attribute certificate string 
values or against string representations of AC OIDs. A number of open 
issues remain to be resolved, e.g., appropriate encapsulation and 
transport protocols. See slides for more details on this presentation.

Revision of PKIX Part 4 (J. Rodriguez-IBM)
Major changes to chapters 3, 4 and 5 have been made. No changes are 
proposed for sections 1, 6, 7, and 8. Revisions to sections 2 and 5 
should be completed before the end of the month. Confusion over 
differences between a CPS and a certificate policy continues, with 
some coordination with ABA ISC. The glossary also needs work. 
Revisions to sections 4 and 3 are slated for completion by the end of 
the year.  Plan to go to last call before the March meeting.


OTHER TOPICS


CMP/CMC Interoperability Testing	(R. Moskowitz-ISSA & C. Adams-Entrust)
Experience with CMP testing workshops, involving 6 vendors, suggests 
some changes should be made to CMP. Most vendors implemented DSA, 
some RSA. Some changes are minor, e.g., default MAC for PKIProtection 
undefined. Major changes include a new Confirm message format and an 
overhaul mapping to various transport protocols (e.g., TCP and HTTP). 
Plan is to issue an ID with changes to RFC 2510 and to complete 
update by March meeting. Denial of service attacks will be better 
addressed by changes to accompanying text. The transport mapping 
discussion may be moved to a separate document. Question is whether 
the revised document can progress to Draft, given that the changes 
are mostly minor, or represent removal of material. The WG co-chairs 
need to contact the Security ADs to discuss the issue of document 
progression. Planning for CMC interoperability testing is now 
underway. See slides for more details on this presentation.

ETSI Electronic Signature Standard (D. Pinkas-Bull)
The intent is to align this technical work with an EU directive which 
is expected to be approved before the end of this year. The goal of 
this standard is to specify what is needed to provide digital 
signatures that are (legally) equivalent to a handwritten signature. 
The scope of this work includes product and service certification, as 
well as technical specifications for protocols and data formats in 
support of electronic signatures. This work assumes the use of 
qualified certificates. The URL for this document was posted to the 
PKIX list for comments. Signature policy is a new element of this 
work, and the policy must be represented in a machine-processable 
form. CMS is base syntax adopted here for signed data, with 
ASN.1-defined extensions to carry a variety of additional data 
necessary to create a non-repudiable transaction. Both CRLs and OCSP 
responses are supported. Two APIs are defined to support these data 
structures. See slides for more details on this presentation.

PKI Disclosure Statements (S. Santesson)
Paper developed with ABA ISC and International Chamber of Commerce 
(ICC). Not a substitute for a CPS or a certificate policy (CP). 
Focus is on most critical elements of a CPS or CP, to be deposited in 
a repository for retrieval by prospective relying parties. CPS and CP 
are too complex and thus there is a need for a simpler, standard 
format to represent the most critical data.  (This is analogous to 
what was required of PCAs in RFC 1422 for the PEM PKI.) First version 
posted to PKIX list today, but we need to decide whether this will 
become a PKIX work item. One lawyer who attends the ABA ISC meetings 
was surprised to hear about this ...

Null Signature Algorithm (A. Malpani-ValiCert)
Motivation in part is that some data structures have a signature as 
an optional feature. One can achieve this effect by making the 
signature an optional data structure; this proposal suggests another 
way to represent this, i.e., by using a NULL algorithm for 
signatures. It also is suggested that this would be useful for 
testing. Comments from the floor were strongly negative. A straw poll 
of the meeting attendees showed strong opposition to adoption of this 
algorithm, so it will be dropped from the work item list.

Jonah Status (M. Shanzer-Iris)
Implementation of RFC 2459, CMP, CRMF, and LDAP (but not CMC or 
OCSP). C++ with a Java GUI, on NT and Solaris. Includes a CA, RA, and 
a trivial end entity. Now uses Cylink toolkit for crypto, but will 
make use of BSAFE soon. Jonah is exportable, but the crypto toolkit 
is not. Tested against NIST, Baltimore, Entrust, Trustpoint and Xeti.

Technical Requirements for Non-repudiation (T. Gindin-IBM)
The document was motivated by the list discussion over the role of 
the NR bit and ancillary certificate and CRL data. Note that the 
services described here do not constitute a complete service for 
legal non-repudiation, but may provide a suitable technical basis for 
legal non-repudiation. An obvious question is how this relates to the 
ETSI work described by Denis?  Based on comments from the audience, 
Tom has decided to remove the legal references from the document, 
modify or delete the text related to the invalidityDate extension. 
The revised document will be issued as a PKIX ID, with the intent of 
publication as an informational RFC in the future. Slides may be 
available with more details on this presentation.