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)