home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pkix / pkix-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  9KB  |  159 lines
  1. PKIX WG Meetings Minutes
  2.  
  3. A total of approximately 190 IETF members attended the PKIX WG 
  4. meetings (two time slots) on 6/25/96.  Steve Kent and Warwick Ford, co-
  5. chairs, presided over the meeting.  Steve Kent  prepared these meeting 
  6. minutes.
  7.  
  8. Agenda
  9.     Introduction
  10.     ISO X.509 Update
  11.     PKIX Part 1 (Certificate and CRL Profiles) Review
  12.     PKIX Part 3 Management Protocols Review
  13.     DoD Management Protocols
  14.     Japanese PKI Report
  15.     ASN.1 Documentation
  16.     Validity Periods
  17.     Reference Implementations & Conformance Testing
  18.  
  19. Steve Kent welcomed attendees to the WG meeting and solicited 
  20. additions to the agenda.
  21.  
  22. Warwick Ford provided a review of the newly revised X.509 AM, based 
  23. on the editing meeting in early June.  A number of changes from the 
  24. DAM have been made, and many of these were motivated by comments 
  25. and suggestions from the PKIX membership.  Major changes relevant to 
  26. PKIX  include criticality bit assignments, key usage, name forms, basic 
  27. constraints, indirect CRLs, hold mechanism, and delta CRL mechanism.  
  28. See Warwick╒s slides for more details of the AM/DAM changes.  The 
  29. AM is available at ftp://NC-
  30. 17.MA02.Bull.com/pub/OSIdirectory/Certificates.
  31.  
  32. Russ Housley reviewed the PKIX Part 1 document, which profiles the 
  33. X.509 AM for Internet use. The document also adds 3 extensions that are 
  34. Internet-specific.  This document describes what it means to support 
  35. each extension, from the perspective of a certificate issuer and 
  36. certificate user.  It also specifies whether the extension is recommended 
  37. or not, and whether it is critical, not critical, or either (at the 
  38. discretion of the CA).  There was almost unanimous agreement that the 
  39. final document must contain the ASN.1 syntax and the accompanying 
  40. processing rules to make this document comprehensive, i.e., so that 
  41. readers will not have to refer to the base ISO document.  Still, there is 
  42. a need to exercise care in creating this mirror document and to track 
  43. defect reports relative to the ISO base document.  Work on this 
  44. document will now move to a phase where WG inputs are needed to 
  45. help decide the status of different extension features, i.e., to 
  46. indicate whether a compliant implementation (issuer or user) MUST, 
  47. SHOULD, or MAY provide support for the extension, plus any Internet-
  48. specific constraints imposed on the syntax of the extension.  See the 
  49. Internet-Draft for details.
  50.  
  51. Stephen Farrell reviewed the status of the current draft of the PKIX 
  52. Part 3 document, which describes management protocols for use with 
  53. certificates and CRLs.  Very little progress has been made on this 
  54. document since the LA meeting, so this was a short report. See the 
  55. Internet draft for more details. A brief discussion of the relationship of 
  56. PKCS-10 to a part of this document ensued, with the proposal that 
  57. PKIX profile PKCS-10.  This suggestion will be explored in more depth 
  58. on the mailing list.
  59.  
  60. Greg Bergren provided a report on DoD work on certificate management 
  61. protocols, analogous to the protocols being described in the PKIX Part 3 
  62. document.  Specifically, Greg spoke of experience gained from work on 
  63. MMP, the MISSI (Multi-level Information System Security Initiative) 
  64. Management Protocol.  Three items were suggested as important 
  65. features present in MMP, but not addressed in the PKIX documents:
  66.     - CA support for mail list (for secure e-mail, e.g., MSP)
  67.     - ability to request a CRL from a CA 
  68.     - support for indirect CRLs (ICRLs)
  69. However, an Internet-specific extension described earlier in this 
  70. meeting already supports CRL requests being directed to various 
  71. destinations.  Also, ICRLs are part of the X.509 v3 extensions being 
  72. profiled.  So, the only major feature of MMP not also encompassed by 
  73. the PKIX Part 3 document, is mail list agent support.  It is not clear if 
  74. mail list support belongs here, since this is an application-specific 
  75. technology, not applicable to most certificate applications.  However, 
  76. several WG members noted that this technology might be more 
  77. generally useful, e.g., for conferencing applications.  Greg offered to 
  78. send a message to the PKIX list  providing pointers to SDN.703  (the 
  79. MMP spec) and to SDN.701 (the MSP specification, for a discussion of 
  80. mail list facilities).
  81.  
  82. Kikuchi Hiroaki described the status of certificate infrastructure in 
  83. Japan, including a discussion of the certification hierarchy deployed 
  84. for PEM use two years ago.  He also provided statistics on PEM use, and 
  85. ongoing work on an expended PKI. Analysis of web of trust for use in 
  86. Japan, based on preliminary experiments and an estimated 100,000 user 
  87. base, suggests a web diameter of about 13.  A full web for a large portion 
  88. of the population would suggest a much larger diameter, but it is not 
  89. clear that even the smaller (13) diameter is viable. One possible 
  90. solution is to have ISPs act as CAs; also an organization for computer-
  91. based authentication (ICAT) is interested in helping organize CAs at a 
  92. national level.  (See http://www.icat.or.jp for more info.)  Use HTTP 
  93. for on-line registration, CRL distribution, and policy statement 
  94. distribution.  User software PEMCAT available for Macs, Windows, 
  95. and UNIX.  Future work will focus on v3 certificates, public key 
  96. algorithms other than RSA, and more experimentation.
  97.  
  98. Steve Kent renewed a call for ASN.1 (88) documentation to help 
  99. facilitate implementation of certificate and CRL processing.  Tim Polk  
  100. agreed to work on providing this sort of documentation from NIST 
  101. resources. It was reported that Burt Kalaski offered to secure copyright 
  102. release for the RSA Labs document, ╥A Layman╒s Guide to a Subset of 
  103. ASN.1, BER and DER╙ for publication as an Internet RFC, either in 
  104. whole or part.  Steve Kent agreed to follow up with RSA Labs on this 
  105. topic.  This document is available via the RSA web site:  
  106. http://www.rsa.com/ftpdir/pub/pkcs/ps/layman.ps (postscript) or 
  107. http://www.rsa.com/ftpdir/pub/pkcs/ascii/layman.asc (ASCII).
  108.  
  109. Denis Pinkas lead a brief discussion of issues related to interpretation 
  110. of the validity period field in the X.509 (v1) certificate. He notes that 
  111. interpretation of this field differs based on whether the signature 
  112. mechanism is being used for non-repudiation or authentication and 
  113. integrity.  For non-repudiation, in the absence of the 
  114. privateKeyUsageValidityPeriod extension, then the private key is 
  115. assumed to have been valid during the validityInterval, but the public 
  116. key is assumed to be valid forever, i.e., for use in verifying signatures 
  117. generated during the validityInterval timeframe.  However, this may 
  118. not be sufficient in all circumstances, e.g., due to concerns over the 
  119. cryptanalytic strength of the signature and/or hash algorithms.  Note 
  120. that for non-repudiation to be effective, one must establish the 
  121. timeframe in which a signature was purportedly applied, and that the 
  122. key used was not reported as revoked during that time frame.  In 
  123. contrast, when the private key is used for encryption purposes, ... Denis 
  124. argues that when the key is used for encryption, the validity interval 
  125. applies only to the public key, and the private key is assumed to ╥live╙ 
  126. forever.  Others note that the definition of this field applies to the 
  127. certificate, not to either the private or public key, but to the binding 
  128. between the public key and the other certificate attributes.  The 
  129. validityInterval field also is interpreted as delimiting the interval 
  130. over which the certificate would be retained on a CRL.
  131.  
  132. Tim Polk talked about NIST activities in the conformance testing and 
  133. interoperability testing arena, and thus his interest in these topics 
  134. relevant to PKIX.  Three NIST projects relevant to PKIX:
  135.     - minimum interoperability specification for PKI components 
  136. (MISPC)
  137.     - conformance testing for PKI components
  138.     - reference implementation for PKI components
  139. MISPC is being pursued by NIST with co-operation/assistance from 
  140. commercial entities, under CRADAs.  Scope includes certificate and 
  141. CRL profiles, CA/RA management protocols, etc.  Work is independent 
  142. of signature and hash algorithms and of underlying transport 
  143. mechanisms.  MISPC should be available by September 30, 1996.  NIST 
  144. will then (staring in September) develop tests to measure conformance 
  145. of PKI components relative to the MISPC.  NIST also wants to develop 
  146. CA, RA, and client reference implementations, for free distribution.  
  147. These implementations should support multiple algorithms and 
  148. provide a sanity check for the test suite.  Existing NIST contributions 
  149. include DSA and SHA-1 code, a CA/RA implementation, and sample 
  150. client software.  NIST is looking for assistance in developing the 
  151. reference implementations.  They have decided that the CRADA 
  152. process is not ideally suited to this task, but they are open to other 
  153. suggestions on how to proceed, e.g., funding or donated development 
  154. resources.
  155.  
  156. Denis Pinkas reviewed (verbally, no slides) a few of his comments 
  157. relative to the Part 1 and Part 3 PKIX I-Ds. Denis╒ comments are 
  158. already available via the mail list, and so are not reproduced here.
  159.