Subject: draft PKIX meeting minutes

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Mar 2002 12:19:14 -0500

PKIX WG Meeting 12/11/01

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

The PKIX WG met once during the 53nd IETF. A total of approximately 145
individuals participated in the meeting. All presentations were
accompanied by slides, copies of which will be posted along with
these minutes.

Tim Polk began with a review of the agenda. Two brief presentations
on non-working group IDs were added to the end, if time permits.

Document Status Overview
	The PKIX Working Group has twenty eight current I-Ds.  Three
I-Ds (Certificate Profile, Public Key Algorithms, and Attribute
Certificate Profile) are in the RFC editors queue for standards track.
Three specifications are in WG Last Call (DPD/DPV Requirements, the
Roadmap and CP/CPS Framework).  All three are projected as Informational
RFCs.  OCSP and the results of interoperability testing have been
forwarded to the ADs for consideration for Draft.  Two additional I-Ds
(CMP and CRMF) are ready to progress to Draft, but Tim Polk and Bob
Moskowitz need to document the CMP/CRMF interoperability testing.
Three CMC specifications (Structure, Transport, and Compliance)
are projected to reach WG Last Call before Yokohama.

       Progression of the PKIX LDAPv3 Schema has been identified as
a priority by the LDAP (v3) Revision working group.  They have requested
that the scope of the PKIX schema document be expanded to include key
information from LDAP v2 documnets that are slated to move to historic
later this year.  The editor has agreed to add the information and
hopes to complete the document before Yokohoma.  This timeline satisfies
the LDAP (v3) Revision WG requirements.

      The Supplemental Public Key Algorithms specification is currently on
hold.  NIST has not published the extended DSA to specify key sizes greater
than 1024 bits.  OIDs have not been assigned for signature algorithms using
SHA-256, SHA-384, or SHA-512.  Finally, the WG chairs have asked the area
directors for guidance on the suitability of lattice-based algorithms for
the Internet PKI.  As these issues are resolved, that document will be
pursued actively again.

DPV/DPD Requirements Status - Denis Pinkas (Integris)
	WG last call now completed. 25+ comments, all being addressed
in revisions underway. Major issues resolved: moved Policy Definition
Requirements (PDP) section to another document, removed "cautionary
period" text, made various changes to remove text that specifies
mechanisms as opposed to requirements, retained mandatory policy
reference but also allows policy parameters to be passed in the
request, only yes or no returned, with status code for no.

SCVP - Ambarish Malpani (ValiCert)
	Incorporating changes based on received comments and will
make changes to match changes in requirements spec. several other
minor changes. A new version will be issued too.

OCSP Update - Ambarish Malpani (ValiCert)
	Interoperability testing done to satisfy progression
requirements. A number of minor clarifications have been made as part
of the progression revisions, as well as a change to make RSA (vs.
DSA) mandatory.

ACRMF & ACMC - Peter Yee (RSA)
	New drafts (issued after SLC meeting) that address attribute
certificate management requirements, i.e., paralleling CRMF and CMC.
ACMC added features to CMC to accommodate ACs. CRMF required fewer
changes to accommodate ACs.

OCKID - Paul Hoffman (IMC/VPNC)
	This new ID specifies a format for human readable data,
distributed out of band, to be used to verify self-signed
certificates or raw keys. It can be used in many contexts to help
distribute trust anchors, OCSP responder credentials, etc. the value
is a 100-bit truncated SHA-1 hash. The spec calls for validation of
the certificate contents vs. the specification of the certificate
type as indicated by the user. This is a possible IPR issue here, a
possible Entrust patent from the WAP Forum. Carlisle Adams will
investigate and report to the mailing list.

Policy Requirements for TSAs - Denis Pinkas (Integris)
	This document is from ETSI and is proposed for publication as
an Informational RFC. It describes various security policies and
procedures for operation of a TSA.

TSP Interoperability Testing - Denis Pinkas (Integris)
	Collection of data from many folks testing TSP client and
server implementations, in support of progression of the TSP RFC
(3161). Note that what is needed here is not just anecdotal evidence
of interoperability, but rather a detailed testing of all the
mandatory features (MUSTS and SHOULDS), including error conditions
resulting from malformed requests and responses.

Permanent Identifiers - Denis Pinkas (Integris)
	Now at version 3, with a number of changes from the previous
drafts, based on extensive, recent discussions on the list. The draft
specifies the format for a new alternative name type (OtherName). The
PI consists of two components: the ID for the owner of the ID space,
and then the ID itself. Presentation explains how the PI is different
from serialNumber and subjectUniqueID attributes.

Proxy Certificates - Steve Tuecke (ANL)
	Motivation for proxy certificates is to name and authenticate
entities that are acting on behalf of users, so as to use this
authenticated name as an input to an access control procedure. Proxy
certificates solves this problem by creating a name for the proxy
that is derived from the user's name, and a means of expressing
limitations on the proxy's access.  Problem is that the proposed
extension would require a change to the validation procedure, and
that would constitute a significant change to the existing standard
and introduce added complexity for all compliant implementations.
Alternatives more recently explored include having users acts as CAs
to issue appropriate certificates, use of ACs, etc.

Logotypes - Stefan Santesson (AddTrust)
	Russ Housley and Trevor Freeman added to editorial team.
Second draft now online. Proposal calls for a new extension that can
represent 3 styles of logotype: issuer organization, subject
organization, and shared community.  Logotype represented by a hash
and URI, pointing to a graphic. Other options being explored include
use in ACs, option for in certificate storage of a reduced resolution
image, standards for image size and format.

RFC 3039 (QC) Updates - Stefan Santesson (AddTrust)
	Will clarify scope of document, also allow use of DS bit with
NR bit in KeyUsage, etc. Relationship to PI work should be explored
as these changes to the QC document are examined.

Non-PKIX Items

Using DNS for X.509 Certificate Storage- Jakob Schlyter (Carlstedt R&T)
	Focus on publishing CA certificates in DNS in CERT record.
Use issuerAltName to lookup in DNS. Use DNSSEC to verify self-signed
certificates. For non-self signed certificates, this is just a
repository proposal, analogous to what was proposed earlier. Will
require examination to determine how this attempt to bridge between
DNSSEC and PKI. Not clear what status is appropriate for this, and
how we should coordinate with DNSSEC WG.

LDAP v3 Schema for X.509 Certificates - Peter Gietz
	Goal of this work is to address limitations associated with
applications dealing with multi-valued PKI attributes in LDAP. The
proposal creates an additional tier of directory entries with
(searchable) attributes that allow existing LDAP clients to search
for and retrieve the "right" certificate. This document defines the
schema for such entries.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 21 Mar 2002 11:39:29 -0800

Steve, Denis:

Wish I could've been there.  The minutes seem to suggest a
transition to a binary yes/no design vs. the trinary
yes/no/unknown approach resolved on the list.  Am I misreading
the minutes?

Mike

DPV/DPD Requirements Status - Denis Pinkas (Integris)
. . . only yes or no returned, with status code for no.

---

From: "Stefan Kelm" <[email-masked]>
Date: Mon, 25 Mar 2002 11:42:54 +0100

Folks,

> forwarded to the ADs for consideration for Draft.  Two additional I-Ds

I haven't been able to find anything in the archive: have the
results of interop testing been published anywhere yet?

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: Stephen Kent <[email-masked]>
Date: Mon, 25 Mar 2002 11:49:01 -0500

>results of interop testing been published anywhere yet?

I have attached the interop test results document that we submitted 
to the IESG in support of advancement. I don't recall whether it was 
posted to the list previously, but since we will need to prepare 
similar test documents for other standards as we continue, this is an 
example of the style of document one might prepare.

Steve
-------

                                                             R. Hurst
                                                             ValiCert
                                                      	    A. Malpani
                                                             ValiCert
                                                             S. Henson
                                                             Celocom
                                                             A. Grant
                                                             Computer Associates

                 X.509 Internet Public Key Infrastructure
                Online Certificate Status Protocol -- OCSP
                         Interoperability Summary

1.    Abstract

       This document summarizes the interoperability resulting from testing
       Various OCSP implementations for compliance and interoperability.

       All tests covered in this document were derived from the OCSP RFC
       [RFC2560].

1.1   Interoperability Results
   
       Results will be specified in the following format:

        Impl. #1         Impl. #1                     Impl. #2
        ------------------------------------------------------
        [ ]              [ ]                          [ ]

       Each implementation evaluated will be given one of the following
       "ratings":

        [?]	Unknown
        [x]	Implemented and interoperates with at least one
                 other known implementation included in this report.
        [-]	Not implemented

1.2   Implementations included in testing

       In this report the following products were included:

  	* ValiCert Enterprise VA 4.2
  	* Computer Associates eTrust OCSPro
  	* OpenSSL SNAP 08-30-2001

       Primary contact for each Implementation includes:

  	* ValiCert              Ryan Hurst      [email-masked]
  	* Computer Associates   Alistair Grant  [email-masked]
  	* OpenSSL               Dr S. Henson    [email-masked]

1.3   Result summary

       It was found that all three implementations were interoperable, in
       all cases tested, additionally it was found that these
       implementations were "compliant" with the OCSP RFC.

Hurst                   OCSP Interoperability Summary            [Page 2]

1.3   Tools used in testing

       Several tools were used while performing testing, these included:
    
  	* Computer Associates - ocspc
  	* ValiCert - vatest
  	* openssl - ocsp
  	* Peter Gutmanns - dumpasn1
  	* Hobits - netcat (nc)

1.4   Responders used in testing

       A variety of responders were used in testing, these included public
       and private responders.

2      Client Generation Request Generation Results

2.1    A Client MAY support the checking of a responder certificate
        for revocation as per section 4.2.2.2.1

2.1.1  A Client MAY check the ocsp-nocheck extension to determine
        if a responder certificate is to be checked for revocation as per
        section.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

2.1.2  A Client MAY determine the responder certificate status
        using the CRL Distribution Point extension in the responder
        certificate.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]

2.1.3  A Client MAY determine the responder certificate status
        using the Authoritative Information Access extension in the
        responder certificate.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

2.1.4  A Client MAY determine the responder certificate status
        using a client configured location and mechanism.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

Hurst                   OCSP Interoperability Summary            [Page 3]

2.2    Client SHALL support including the ServiceLocator extension
        with its requests as per sections 3.1, 4.2.2.2.1 and 4.4.6

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

2.3    Clients MUST support sending "unsigned" OCSP requests as
        per Appendix C

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  

2.4    Clients MUST support the RSAwithSHA1 signature suite as per
        section 4.3

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  

2.5    Clients SHALL support the response type of BasicOCSPResponse
        as per section 4.2.1

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  
     
2.6    Clients MAY support including a nonce in requests as per
        section 4.4.1

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]     
     
2.7    Clients MAY with to include the "Acceptable Response Types" it
        supports within its requests as per section 4.4.3

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]       

Hurst                   OCSP Interoperability Summary            [Page 4]

3      Server Request Processing Results

3.1    In error conditions it is possible for a responder to return a
        unsigned error response.
	 
3.1.1  Server MAY handle incorrectly formatted requests by returning
        the error "malformedRequest" as per section 2.3 in the OCSP RFC.
        This case was reproduced by generating a valid OCSP request and
        modifying a single bit of that request
        to contain a bogus value.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

3.1.2  Server MAY return the error "internalError" when it encounters
        an internal error as per section 2.3 in the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

3.1.3  Server MAY return the error of "tryLater" to indicate
        that the service exists, but is temporarily unable to respond
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [?]              [?]                          [?]

3.1.4  Server MAY return the error of "sigRequired" to notify
        a client that it requires responses to be signed.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
     
3.2.1  Servers MUST support http as a transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

3.2.2  Servers MAY support https as a transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
     
3.2.3  Servers SHOULD support HTTP POSTs

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

Hurst                   OCSP Interoperability Summary            [Page 5]

4      Server Response Generation Results

4.1    Server SHOULD be capable of generating responses for multiple CertIDs

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.2    Responses include several time dependant values, these values
        are documented in section 2.4 of the OCSP RFC.

4.2.1  Server SHOULD include a response validity interval as per section
        2.2 and 2.4 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.2.2  Server MUST include the producedAt extension as per section 2.4
        of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.3.1  Server MUST be capable of returning definitive response of "good"
        as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.3.2  Server MUST be capable of returning definitive response of "revoked"
        as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.3.3  Server MUST be capable of returning definitive response of unknown
        as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

4.4    Server MAY support the optional pre-production of responses
        as per section 2.5 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]

Hurst                   OCSP Interoperability Summary            [Page 6]

4.5    Server MAY support the optional "CA Key Compromise" scenario as per
        section 2.7 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [x]                          [-]

4.6    Server MAY support including a nonce in responses as per section
        4.4.1

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

4.7    Server MAY support including the optional CrlID (CRL References)
        extension in responses as per section 4.4.2

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [-]              [-]                          [-]
     
4.8    Server MAY support including the optional "CRL Entry Extensions"
        in responses as per section 4.4.5

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
     
4.9    Servers MUST support sending responses of type: BasicOCSPResponse

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]  
     
4.10   Servers MUST support identification of responder byName

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

4.11   Servers SHOULD support identification of responder by keyId

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

Hurst                   OCSP Interoperability Summary            [Page 7]

5      Client Response Processing Results

5.1    Verification Trust Models

5.1.1  Clients MUST support verification of CA Signed results as per section
        2.2 in the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.1.2  Clients MUST support verification of responses signed by a directly
        trusted responder as per section 2.2 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.1.3  Clients MUST support verification of responses signed by a CA
        designated responder as per section 2.2 and 2.6 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.2    Error cases

5.2.1  Clients MUST support processing of malformedRequest error responses
        as per section 2.3 of the OCSP RFC. This test was produced by
        sending the Verisign OCSP responder a signed OCSP request.
        at the time of testing this responder is known not to support
        signed requests, as such it will respond in this matter.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.2.2  Clients MUST support processing of internalError error responses
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x] 

5.2.3  Clients MUST support processing of tryLater error responses
        as per section 2.3 of the OCSP RFC. Support in this case denotes
        successfully handling the error, not necessarily trying again.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

Hurst                   OCSP Interoperability Summary            [Page 8]

5.2.4  Clients MUST support processing of sigRequired error responses
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
        
5.2.5  Clients MUST support processing of unauthorized error responses
        as per section 2.3 of the OCSP RFC.

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.3.1  Clients MUST support http transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]

5.3.2  Clients MAY support https transport

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]
      
5.3.3  Client supports http POSTs

        OpenSSL          Computer Associates          ValiCert
        ------------------------------------------------------
        [x]              [x]                          [x]