Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/pkix/pkix-minutes-97apr.txt

Text File | 1997-05-29 | 17KB | 387 lines

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


PKIX WG Minutes, April 7-8 1997  (Reported by Michael Myers, VeriSign)


SUMMARY

The PKIX WG met in two sessions at the April 1997 IETF meeting in Memphis.
The main agenda topics were status briefings on Parts 1, 3 and 4 of the
PKIX document set and an initial briefing Part 2.  In the follow-up
session, several technical amendments were proposed, discussed and moved
forward.

There was also an informational presentation drawing attention to an
alternative certificate management protocol based on HTTP and HTML
technology.  This information was presented for the WG's consideration in
the development of the IETF standard certificate management protocol.

Parts 1 and 3 will transition to WG Last Call following this IETF.  Part 2
will take longer, but is also targeted for standards track.  Part 4
provides guidance for authors of certificate policies and certification
practice statements, and is targeted for an Informational RFC.  Additional
work is expected in the areas of Attribute Certificates and their
relationship to access control, Timestamping and Notarial services, and the
evolution of PKCS #10.


MONDAY, 7 APR 97

PART 1:  CERTIFICATE AND CRL PROFILES

Tim Polk presented the changes to Part 1 between the Dec. 96 draft and the
current draft.  These were:

* Reduced private extensions from three to two, both non-critical
* Eliminated sliding window for time encoding, instead a fixed date.
* URIs in alt name fields point to certificates in repositories
* URI in authority InfoAccess points to on-line validation service
* Cylink patent statement added
* ASN.1 is believed complete
* ASN.1 EXPLICIT/IMPLICIT problems corrected
* KEA encoding added
* Examples added
* Improved references

OPEN ISSUES
* RSA patent statement still outstanding, should be resolved soon.
* Examples:  expand?  remove?
* ASN.1 checking (check '88 vs. '93 constructs)

It is the intent of the WG that Part 1 will go to WG Last Call following
this IETF.

DISCUSSION
1.  KEA is an unpublished algorithm.  References to it in Part 1 should be
removed.

Resolution: References to KEA will be removed from Part 1.  Parties
interested in such a specification may publish an informational draft
addressing the issue.

2.  The RSA patent statement is still an outstanding issue, but it should
be resolved soon.

Resolution:  Tim Polk will take action to move this issue to closure.

3.   The current draft indicates 1996 date, should be changed to indicate a
1997 date.

Resolution:  The document will be changed to reflect the correct expiration
date. The title of the Part 1 document correctly indicates version 4.


PART 2:  OPERATIONAL PROTOCOLS

Sharon Boeyen presented the work to date on Part 2 regarding the use of
LDAP and FTP for retrieval of certificates and CRLs and the requirements
for and specification of an Online Certificate Status Protocol (OCSP).

DISCUSSION
1 - Should we consider splitting the document into two separate ones, since
the OCSP is a new protocol definition which may require significant more
review and discussion than the LDAP and FTP profiles?

Resolution: Although we agree that OCSP may require additional review, the
document will remain a single draft and we will re-address this issue, if
the OCSP discussion is such that it will require a longer review period and
impede progression of the remainder of the document.

2 - A question was raised about privacy when searching directories via LDAP
(e.g. email addresses may not be made public).

Resolution: The intent of PKIX part 2 is NOT to suggest that any attributes
need to be made public. If some attributes, such as email addresses, happen
to be public information, then the LDAP profile defined in PKIX part 2 will
support searching on such attributes.

3 - A question raised regarding the requirement of a public key operation
on each OCSP validation operation and had there been any consideration
given to ways to reduce that requirement.

Resolution: Some support for reducing the load on the server can be
provided by caching signed responses for frequently requested certificates.

4 - A question was raised on the specific contents of a ".cer" file.

Resolution: Each .cer file contains exactly one certificate, encoded in DER
format.

5 - LDAP profile for adding, modifying, deleting PKI information was raised
as an issue - should these operations be added to PKIX part 3 (since they
are data management operations) or should they be added to PKIX part 2
(keeping the complete LDAP profile together).

Resolution: The LDAP operations will be profiled in PKIX part 2 and
appropriate references added to PKIX part 3.

6 - LDAP versions

Resolution: The progress of LDAP v3 will be tracked and when stable,
consideration will be given to moving this profile from v2 to v3. V3
support for strong authentication will probably help satisfy some concerns
raised over the ability of someone to masquerade as a repository.

PART 3:  MANAGEMENT PROTOCOL

Carlisle Adams presented the current state of Part 3.  The current draft
currently resides on Entrust's web server at www.entrust.com.  It will be
moved to the Internet Drafts directory after the IETF.

Substantive changes from the previous draft:
* Addition of PKCS 10 as a valid certification request message.
* Recognition of PKCS 7 as an alternate security protocol.
* Text regarding Proof of Possession (POP) of a private key.
* Added a challenge-response mechanism in support of Registration Authorities.

It is the intent of the WG that Part 3 will go to WG Last Call following
this IETF.

DISCUSSION
1. It was pointed out that the current statement regarding PKCS 10 usage
was overly specific as to the allowable context of its use.

Resolution:  The text will be amended to generally accommodate PKCS 10
requests.

2.   At the San Jose meeting, a general consensus was established within
the WG that evolutionary support for PKCS 7 & PKCS 10 is desirable as an
alternative to PKIX Part 3.  A question was raised regarding the current
status of this issue.

Resolution:  It should be expected that work will be performed to advance
PKCS 10 forward to address requirements met by Part 3.

3.  More flexibility in the statements regarding requirements on POP is
desired.

Resolution:  The editor will amend the text to more fully express the
intended flexibility.

4.  A question was raised concerning the exact definition of "operational
protocols".

Resolution:  The term "operational protocols"  within PKIX refers to those
relevant to delivering PKI services.  Application protocols, e.g. S/MIME or
TLS, are out of scope.

5.  It was noted that there is no means to indicate a type of CA in the
certification request.

Resolution:  Type of CA is defined by policy OID or by reading the CPS.

6.  The challenge-response protocol appears to be predicated upon state
information established during prior message exchanges.  Is it possible to
reduce a registration process using this protocol to a single exchange?

Resolution:  A requirement for a single-pass exchange in this instance
cannot be met by the challenge-response protocol as defined.  It should
also be noted that the protocol in question only addresses proof of
possession of encryption keys.


7.  In the challenge-response model of registration, can the RA reformat
the request received from the subscriber when forwarding it to the CA?

Resolution:  Yes.  The intent is to establish a general model of
Subscriber-RA-CA interaction that is extensible to detailed operational
requirements.  The RA may choose to simply re-encapsulate the subscriber's
request, but is not required to do so.  The RA could receive a certificate
request in one format and forward to a CA in another format.

8.  It was asked if conformance to Part 3 is defined by the text, or by the
tables in Appendix B, or if there should be some other external document
defining conformance.

Resolution:  It is the authors' intent that the tables in Appendix B define
conformance.  A blanket statement will be added to the text to clarify this
intent.



PART 4:  POLICY GUIDELINES

Santosh Chokhani presented details on status of Part 4.

1.  A questioner asked if Part 4 is intended to be prescriptive with
respect to the Internet.

Resolution:  It is beyond the scope of Part 4 to prescribe Internet
certificate management policy or acceptable certification practices.  Part
4 is informational in nature, and intended as an aid to the development of
certificate policies and certification practices statements.  Any
requirement governing the implementation of automated certificate policy
recognition and decision logic will be addressed by Part 1. LDAP could be
used to gain access to electronic policy elements, to the extent such
policy elements exist.

2.  There was an observation that the document does not discuss storage of
CRLs, or the role of repositories generally.

Resolution:  It was pointed out that Part 4 does indeed recognizes the
existence of repositories, their role with respect to CRL distribution and
provides some discussion of their relevance to the overall PKI policy
management solution.  Part 4 does not establish policy; rather, it
identifies the elements that may be included in a certificate management
policy.  It was ultimately recognized that additional work was needed on
specific obligations for CRLs and repositories.

3.  It was proposed to the working group that IANA institute procedures to
serve as a policy element registration authority for the purpose of
establishing PKIX-Internet wide policies.

Resolution:  PKIX has an item on "Guidelines for policy definition and
registration", but this does not include the definition of specific
policies.  The proposed initiative lies beyond the original scope
discussions of the WG.  This is also consistent with the general nature of
the IETF, which is inherently an Engineering group.  It would, however, be
reasonable for the IANA to define an OID arc under which certificate
policies might be registered.  (It was subsequently noted that such an arc
already exists.)


TUESDAY, 8 APR 97

KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY

Hiroaki Kikuchi presented an alternative to PKIX part 3.  The proposal
addresses an HTML-based value encoding instead of BER encoding for the
purposes of human readability.  It further presents an alternative
text-based protocol for various certificate management functions.  A
software package--ICAT CA Package ver 1.0, implementing the described
functionality is available at:

    ftp://ftp.icat.or.jp/pub/interauth/icap


DISCUSSION

It was noted that the proposal needs to be updated to reflect the reduction
of PKIX private extensions from three to two.

Part of the proposal involves the use of relative URLs.  It was noted this
is useful if all operations are confined to a well-known repository; the
general case suffers, however. One repository would not work in general.

The HTML is still not all that readable.  Hiroaki concurred that some of
his colleagues have made the same observation.

It was hypothesized that an HTML representation of a reasonably complex
certificate would be substantially larger than its corresponding ASN.1
equivalent.  Hiroaki drew attention to the fact that the HTML syntax maps
one-to-one to BER encoding rules.

Hiroaki accepted the invitation to write a contribution for Part 2 dealing
with the use of HTTP to obtain certificates and CRLs from a repository.

CERTIFICATE STORAGE INTEREST GROUP

Christopher Allen of Consensus Development discussed a proposed
standardization activity on personal information storage .  Schemes under
consideration include PFX and a scheme that is substantially simpler than
the current PFX proposal.  Under the second proposal, all information
relevant to the transport of a subscriber's security context would be
encapsulated in an "ASCII-armored" format, formatted using base-64
encoding.  Internal to the storage context, PKCS 7 would be used for
certificate and CRL encapsulation and PKCS 5 and 8 for private keys.

Interested parties are encouraged to participate in a mailing list
dedicated to this topic ([e-mail], subject: subscribe).
 If sufficient interest accumulates around the topic, a BOF may be formed
at the next IETF to consider moving the topic forward more formally.

TIMESTAMPING / NOTARIES

Carlisle Adams proposed that PKIX begin work in this area, based on ISO
13888 part 3.  Several members of the WG, including representatives from
BBN, Spyrus and VeriSign, offered to participate.

TLS LIASON

Rodney Thayer, Christopher Allen and Tim Dierks of TLS working group led a
discussion on the relationship between TLS and PKIX.  Following are issues
raised, and their corresponding resolution:

1.  It was noted that the current PKIX Part 1 does not spell out use of MD5
as a supported alternative.  The text and corresponding examples are
inconsistent in their suggestion of MD5 as a requirement.  MD5 is required
in order to enable the mandatory TLS cipher suite.

Resolution: PKIX Part 1 will be amended to provide the necessary support.

2.  There exists some uncertainty as to the interpretation of KeyUsage bits
when applied to the TLS protocol.  Part 1 should make explicit the
circumstances applicable to given KeyUsage bits.

Resolution: Text will be added to provide additional guidance on the
assignment of KeyUsage bits.  In particular, it was agreed that
DigitalSignature should be set for client certificates, since TLS clients
signs an object (the MasterSecret of the TLS protocol.).  In the case of
server authentication, the server's decryption and subsequent successful
use of the client's keys (which were encrypted under the server's public)
is proof of server authentication.  In this case KeyEncipherment shall be
set.  When ephemeral RSA is used to sign an ephemeral DH key,
DigitalSignature shall apply.  (See also Extended Key Usage below.)

3:  It is preferable to be able to express name strings containing regular
expressions for the purpose of flexible domain administration and load
balancing.  Clarification was requested as to whether such constructs are
to be included in the Subject Name of the base certificate, or in the
dNSName variant of SubjectAltName.

Resolution:  Use SubjectAltName.


PART 1 MODIFICATIONS

Enhanced Key Usage

The current key usage bits extension is insufficient to meet needs to
identify the full set of purposes for which a public key may be used.  The
following syntax was proposed at the meeting.

KeyPurpose ::= SEQ SIZE (1 .. MAX) of OBJECT IDENTIFIER

PKIX-1 defines OIDs for all defined values of KeyPurpose.

KeyPurpose will be presented to ISO as standard replaced for KeyUsage.

There was an observation that the certificate policy extension could be
used to satisfy this requirement.  It was felt however that certificate
policies are conceptually orthogonal to key purpose.  Certificate policies
express a measure of reliance strength, independent of purpose.

After much debate, it was decided to retain the existing KeyUsage bits and
propose another standard extension called enhancedKeyUsage (or
extendedKeyUsage) to carry the purpose OIDs.

AuthorityInfoAcces syntax

Kevin Vogel described the need for additional flexibility to define new
formats for CRL retrieval in a standard fashion.  He suggested reverting
back to the December 96 draft concepts.  The following syntax was proposed:

AccessDescription::=SEQUENCE {
format OBJECT IDENTIFIER default PKIX2
location GeneralNAME }

AuthorityInfoAccessSyntax ::= SEQUENCE {
    authorityInfo    [0]  GeneralName    OPTIONAL
    statusInfo    [1]  SEQUENCE OF  accessDescription OPTIONAL }

Keith also requested that AuthorityInfoAccessSyntax be defined as an
ATTRIBUTE so it can be included in PKCS 7 messages.  This would be used to
point to certificate storage area, given only the Issuer DN + cert. serial
number in SignerInfo of PKCS 7.  With the ability to automatically locate
certificates by reference, they  need not be included in the PKCS 7
encapsulation, thus reducing its size.



---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [e-mail]; Tel: [phone] x225; Fax: [phone]
---------------------------------------------------------------------