PKIX WG Meeting July 26, 2010

 

Edited by Steve Kent

Co-Chairs: Stephen Kent <kent@bbn.com>

 Stefan Santesson <stefans@aaa-sec.com>

 

The PKIX WG met once, for 2 hours, during the 78th  IETF. A total of approximately XX individuals participated in the meeting.

 

 

Document Status Review - Stefan Santesson (3xA Security)

There has been significant progress in document status since the previous meeting.

-   5 RFCs published since Anaheim: 5816, 5877, 5912, 5913, 5914

-   1 document in the RFC EditorÕs queue: TAMP (the protocol)

-   4 documents in IESG processing: ASN.1 translation, OCSP agility, TAM requirements, certificate image

-   2 I-Ds in process in the WG: CMC Updates, 5280 clarifications

-   2 non-WG documents under consideration: updating AKI and SKI, Transport protocols for CMP

(Slides)

 

PKIX WG Documents

 

OCSP Agility – Stefan Santesson (3xA Security)

 There were a few minor typos in the ASN.1 for this I-D (which is in IESG evaluation). There is also a need to agree on how to specify parameters for signature algorithms. (see the OCSP Update presentation later). Jim Schaad suggests use of an S/MIME algorithm capabilities representation vs. the current algorithm ID approach. There was general agreement in the room to do this, and a recognition that this will require returning the document to the WG, having a second WG last call, then forwarding it to the IESG, again. (Slides)

 

CMC Updates – Jim Schaad (Soaring Hawk Consulting)

     Jim has revised the document and will resubmit soon. He is waiting for feedback (from Sean Turner) to ensure that the document covers all of the CMC functions that SeanÕs application requires.

 

 

RFC 5280 Clarifications – David Cooper (NIST)

     Since the last meeting, David added BMPString as an acceptable encoding for the explicitText field of the user notice policy qualifier, as per WG agreement. An open question is whether the document should say that a CA SHOULD normalize a UTF8String BMPString in this context? Paul Hoffman suggested that this is a reasonable thing to say, although it is hard to test, because most implementations encode what a user enters via a keyboard, and that usually is in normalized form. A WG last call was initiated on June 8. Most of the comments received were deemed out of scope and may be considered when 5280bis is generated. (Slides)

 

 

Updating OCSP – David Cooper (NIST)

     This is an ongoing effort to remove ambiguities in RFC 2560, and to incorporate the algorithm agility features documented later. In particular, there is a significant discussion about section 4.2.2.2,which discusses the trust model for OCSP. David plans to make a change to the OCSP text top align more closely withy RFC 5019 (OCSP-lite). The text will update the mandatory and optional algorithms list, define the new request extension to express algorithm preferences, and to specify rules for responder signature algorithm selection (as per the algorithm agility RFC). David has introduced new terms to clarify the three types of roles for OCSP responders. The discussion in the room showed that there are still many contentious issues here, and thus this will take a lot more work on the list to resolve these issues. The WG needs to decide if the document should be a bis (obsoletes) vs. an ÒupdateÓ in the usual sense. David, the WG chairs, and both ADs believe that there are so many changes that a ÒbisÓ makes sense here, even if the intent is still that of an Òupdate.Ó We will take this to the list to seek confirmation.

 

David also raised a set of new issues for the OCSP work, including how a server should handle unrecognized critical extensions, whether there is a need to change the response (from unknown to good) generated in a Òrace condition.Ó This problem probably arises because of a contentious OCSP topic, i.e., an effort by some folks to have ÒgoodÓ be a substitute for a certificate validation response. The WG did not agree to this, and this issue seems to be an effort to resurrect this debate. David also discovered a gap in the ASN.1 spec for the nonce extension. There is agreement that the missing ASN.1 MUST be included in the document, along with text explaining how to deal with the backward compatibility issue. Other issues included in DavidÕs slides will be discussed on the list. (Slides)

 

Presentations on non-WG Topics (seeking WG adoption)

 

Updating AKI and SKI (Sean Turner – IECA, Steve Kent - BBN)

     The goal is remind implementors that using SHA-1 to generate key ids is only an example inn 5280! In a growing number of contexts, there is a mandate to replace SHA-1 with SHA-256, even though this is not security relevant in this context. There are several ways one could do this. For example, a document could just tell people how to extract 160 bits (SHA-1 length) from other hash algorithms and put it into the AKI/SKI field, without confusing existing implementations that may be wedded to 160-bit lengths for these fields.  Stefan Santesson agreed to ask the list to approve WG adoption of this topic. (Steve Kent is a co-author, so he has recused himself from WG chair decisions related to this document.) (Slides)

 

Transport Protocols for CMP – Martin Peylo (Nokia Siemens)

     The speaker has been developing an open source CMP patch for OpenSSL. His employer is interested in this because 3GPP (TS 33.310) makes use of CMP (vs. CMC) and thus the cell phone industry wants to have a solid spec for using CMP. The speaker also created the wireshark software module to decode CMP. The principle focus here is on HTTP as a transport protocol, the protocol that the 3GPP folks want to use. The draft that the speaker wants to resurrect was abandoned by the original authors over 4 years ago. The speaker contacted the original authors: one (Kause) will help a bit with the new document, but the other two authors (Tschalar and Kapoor) will not participate. The later two names would be removed from the authors list, and moved to the Acknowledgements section, if the document is allowed to proceed as a PKIX item. The list will be asked to approve this as a new WG item. (Slides)