Editor's note:  These minutes have not been edited.


		       PKIX WG Meeting Minutes

			(December 9-10, 1996)


	The PKIX WG met for two days at the December IETF meeting in

San Jose.  Approximately 200 IETF members attended the two meetings.

The main agenda topics were status/update briefings on Parts 1 and 3

of the PKIX document set, and an initial briefing on certification

policies, the focus of the Part 4 document.  There also was a
presentation

on a technique for requesting a certificate containing a
Diffie-Hellman

key, which requires a mathematically different approach to verifying
that

the requester holds the corresponding private key.


	There were also several informational briefings on topics of

interest to the PKIX WG.  M. Polk provided a status update of the NIST

MISPC activity, and B. Blakley provided an extensive briefing on the

APKI Working Group (not an IETF WG) activity, relating this

architecture to IETF standards activities.  This presentation

generated a substantial number of questions, at least in part because

of its inclusion of facilities for key escrow/recovery.


	The Part 1 document is nearing completion, and was briefed by

a new document editor, M. Polk, and by R. Housley.  Major changes

include a revision of the validity interval syntax (to better deal

with the year-2000 problem), inclusion of syntax for the PKIX

(private) extensions, etc.  Several suggestions for changes (most

minor) were made after the briefing, by D. Pinkas.  It was agreed that

these changes would be discussed on the WG mailing list after the

meeting.  The WG chairs called for rapid resolution of these issues

and document completion, to enable a WG last call early in 1997.


	M. Polk provided a brief update on the status of the MISPC

activity at NIST, as a successor to a similar briefing provided in

Montreal.  For the most part, the resulting NIST specs match the PKIX

specs (parts 1 and 3), with minor differences.  For example, there are

no private extensions defined and there is a requirement for non-null

subject and issuer DN fields.  With regard to algorithms, ECDSA, DSA,

and RSA are all defined and support for at least one of these is

required.  LDAP is required for repository access, and the NIST spec

does not include any CA-repository protocols; it also accommodates

PKCS-10 request formats, embedded in PXIK message formats.  90-day

comment period began 12/2, and after review a NIST Special Publication

will be produced.


	D. Solo provided a brief presentation on certificate requests

that contain Diffie-Hellman keys.  The focus here is on the means by

which the requester uses his private key to "sign" the request, since

D-H does not support signatures.  The context for this certificate

request is the PKCS-10 specification.  The basis of the "signature" is

a D-H key generated between the requester and the CA (the CA must have

a D-H certificate for this purpose), which is then input to a hash

including the requester and issuer names, and the resulting output is

used as a key for an HMAC computation covering the text of the request

message.


	The presentation on the Part 3 document was made by its

authors, S. Farrell and C. Adams.  Major changes include

simplification of the ASN.1 syntax, added message types (e.g.,

information requests and responses, publication, private key archive),

some new security services for RA/user-CA communication.  There are

some differences between proposed "proof of possession" approaches for

D-H keys, vs. what D. Solo presented.  This difference needs to be

resolved.  Also, there was some concern that this protocol might be

"close" to the Bellovin-Meritt encrypted key exchange, which is a

patented algorithm.  An issue was raised about using PKCS-7 as a

security envelope technique, in lieu of some of the current Part 3

format This would simplify the document and re-uses existing code,

although it also creates a dependency on another document.  A straw

poll suggests widespread support for PKCS-7 in this context. There is

a separate issue about use of PKCS-10, which is somewhat less powerful

than what is currently offered.  Thus the suggestion is to make

PKCS-10 a format option, but not the only format option for

certificate request messages.


	The PKIX Part 4 presentation was the first on this part of the

PKIX document set, and was provided by S. Chokhani.  This was a

informational briefing on the topic of certificate policies, as well

as providing technical details for a proposed certificate policy

framework.  The framework encompasses 9 top-level elements: community

definition and applicability, I&A policy for subjects/RAs/CAs, key

management policy, non-technical security policy, technical security

policy, operations policy, legal & business provisions, certificate

and CRL profiles, and policy administration.  This is all viewed as

human, not machine, readable.  The machine readable aspect is

captured by the use of the policy OIDs and policy qualifiers.


	The meeting concluded with a brief announcement of the

formation of a BOF and a mailing list to address the topic of

certificate (and private key) storage.

</bigger></bigger></fontfamily>