draft WG meeting minutes
Stephen Kent <kent <at> bbn.com>
2000-08-02 02:24:44 GMT
The draft minutes for today's WG meeting are reproduced below. I'll
accept corrections until 8/11.
Steve
-------
PKIX WG Meeting 8/1/00
Edited by Steve Kent (WG co-chair)
The PKIX WG met once during the 48th IETF and a total of
approximately 180 individuals participated in this meeting.
The meeting began with the announcement that Tim Polk of NIST will
take over from Warwick Ford as a co-chair of the WG. Warwick received
a round of applause from the audience, for his service to the Wg
since its inception.
Tim began the meeting with a review of the status of all of the WG
documents. The following text summarizes the status of the documents:
PKIX COMPLETED DOCUMENTS (RFCs)
PKIX Cert/CRL Profile (RFC 2459)
HTTP/FTP Operations (RFC 2585)
LDAP V2 Operational Protocols (RFC 2559)
LDAP V2 Schema (RFC 2587)
OCSP (RFC 2560)
CMP (RFC 2510)
CRMF (RFC 2511)
CMC (RFC 2797)
Diffie-Hellman POP (RFC 2875)
Certificate Policy/Practices Guideline (RFC 2527)
KEA Algorithms for Profile (RFC 2528)
PKIX WORK IN PROGRESS (Internet Drafts)
Revised Profile (draft-ietf-pkix-new-part1-02.txt)
Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt)
Qualified Certificates (draft-ietf-pkix-qc-05.txt)
Time Stamp (draft-ietf-pkix-time-stamp-09.txt)
PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)
Revised CMP (draft-ietf-pkix-rfc2510bis.01)
CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt)
Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt)
Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt)
Attribute Certificate Profile for Authorization
(draft-ietf-pkix-ac509prof-04.txt)
Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt)
DCS (draft-ietf-pkix-dcs-05.txt)
Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt)
Permanent Identifier (draft-ietf-pkix-pi-00.txt)
Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt)
Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt)
ACTIVE PROJECTS:
LDAP v3 Profile (D. Chadwick-U. of Salford)
Split profile into two pieces: protocol vs. schema. The protocol
parts should be completed in the next 6-8 weeks and be ready for WG
last call. (Suggestion that the LDAP WG also be included in this last
call.) The schema work will take longer, as it is a new topic. A
major change for the schema is to allow searching on certificate
fields, rather than searching on the directory attributes extracted
from the certificate. For now, plan to keep the schema work related
to certificates in PKIX, not in an LDAP WG, with David acting as
principal liaison between the two groups.
RFC 2459 evolution (T. Polk-NIST)
2459 has been split into algorithm profiles vs. certificate & CRL
syntax and processing. This allows the algorithms document to be
revised as algorithms change, without affecting the syntax and
processing standard. There is little new material here, mostly
clarifications, editorial revisions, etc. We will hold a straw poll
on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With
the end of the RSA patent period, many other security WGs are taking
similar steps. Also, if the WG decides to identify mandatory
algorithms, we need to decide whether they are specified in the
certificate and CRL processing document, or in the algorithms
document. (See slides for more details.) We should be able to go to
WG last call very soon on these documents.
Qualified Certificates (S. Santesson-AddTrust)
Discussions at this IETF meeting have resolved the few remaining
points of contention with regard to this draft. Minor changes in
wording will result in a new draft by the end of this week and this
draft will be forwarded to the security area directors to proceed
with the IESG last call.
Permanent Identifiers (D, Pinkas-Bull)
To be used only in certificates issued to individuals. Designed to
track real world identity in the face of name changes, e.g., marriage
or job changes within an organization. The ID is expressed as a new
name type, with two components; an assigner authority and a name. The
first component may be omitted, in which case the certificate Issuer
is presumed to be the assigner authority. Note that a registered ID
(from general name form) has the necessary property that it is
globally unique, and permanent (although not directly meaningful).
Thus, depending on which general name form is employed, one can
compare names either within a CA domain, or globally, across all CAs.
Plan for now is to proceed with it as a separate document, not merged
with the QC or son-of-RFC-2459 documents. (See slides for more
details.)
Time Stamping Protocol (D. Pinkas-Bull)
Now on version 9. Several changes made after last call completed.
Changes include definition of the serial number consistent with 2459
(can even be a hash of up to 160 bits!), change to SIA from AIA, etc.
A number of minor wording changes were made, but the restriction on
exclusive use of the TSA private key for signing responses has been
preserved. Ready for forwarding to the IESG.
Preface to OCSPX and SCVP discussions: As proposed at the Adelaide
meeting, a small group was formed and generated a requirements
document to characterize the motivations for remote validation
services, to define the requirements for such services. The group did
not compare the candidate protocols relative to these requirements.
OCSP Extensions (M. Myers-VeriSign)
Previous ID has expired, expunged from IETF web site. Mike argues
that OCSP is the right choice for remote path processing (RPP), via
the addition of extensions. Proposal is to revise RFC 2560, to fix
minor problems, clarify OCPS role as a framework for remote
validation services. Then, create separate documents to define
extensions for remote path validation, remote path discovery, etc.
So, there would not be an OCSPX document, but rather definitions for
syntax and processing for standard extensions. (See slides for more
details.)
D. Pinkas provided some slides addressing the parameters of remote
path processing, e.g., how the requestor constrains the path
processing or path construction operation. So, the format needs to be
able to indicate whether the requestor wants CRLs or OCSP responses,
what security policy to use in evaluating a certificate path, other
constraints, etc. Denis argues that the requirements document needs
to cover more of these details. However, Paul Hoffman noted that the
group was not able to agree to a larger set of "requirements." (See
slides for more details.)
SCVP (A. Malpani-ValiCert)
The speaker reviewed RPP requirements and what OCSP does to support
part of the process. Ambarish argues that changes to OCSP to meet
these extended requirements may break existing OCSP implementations,
and that the code base for OCSP is small, so there is not much to
leverage in building an RPP protocol. SCVP will support both ASN.1
and XML, consistent with perceived client requirements to retain data
in this format. (See slides for more details.)
Attribute Certificates (S. Farrell-Baltimore)
Profile has been updated, synchronized with latest X.509 version, and
has completed WG last call. It is suggested that this document
reference the successor to 2459, which clears up the residual
reference issues.
CMP (C. Adams-Entrust)
CMP RFC is being revised to reflect minor changes. Plan is to wait
until completion of interoperability testing (in the PKI forum) to
finalize changes to this document, to reflect any further
clarifications that arise from this testing.
Repository Locator (P. Hallem-Baker-Verisign)
Goal of this document is to specify a means by which one can map an
RFC822 name for a user to the LDAP server where the user's
certificates are stored. The proposed approach is to use the SRV
record in the DNS to provide the necessary pointer. The SRV record
is analogous to an MX record, but more general, supporting a list of
services and matching addresses. Open questions include the
internationalization of DNS (which the DNS WG will address), plus
communicating conventions for access protocols (LDAP, HTTP, ...). The
base document is a very small work item, because it is merely
profiling the existing SRV record. Separate documents will be
generated to describe each access protocol convention, e.g., LDAP,
OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on
their plans for using SRV records for LDAP directory location. (See
slides for more details.)
CMP Interoperability testing (B. Moskowitz-ICSA)
ICSA is working with PKI Forum to coordinate these interoperability
tests. Three workshops have been conducted to date, with more
scheduled for August and September. Various algorithms, transport
protocols, POP mechanisms have been tested. A number vendors have
participated. Planned public demo at NISSC in October. Experience
shows that variants in CA-side implementations do cause
interoperability problems, and further clarifications are needed in
RFC 2510 to help resolve ambiguities. CMC interoperability testing
may also be pursued in the future.
RSS Feed