IETF 58th Meeting Hilton Hotel - Minneapolis, Minnesota SMIME WG 11 November 2003, 1700-1800 INTRODUCTION The meeting was chaired by Blake Ramsdell of Brute Squad Labs. The other co-chair, Sean Turner of IECA, was unable to attend. Approximately 40 participants were in attendance. The Chairman introduced the agenda. There were no comments on the agenda from the WG. He acknowledged that Chris Bonatti agreed to serve as note-taker. He asked for an official XMPP scribe, but there were no volunteers. So the Chairman suggested that anybody using XMPP act on their own recognizance to highlight important statements over that service. WG STATUS The Chairman gave an update of the status of WG activities. He reported the following: There are two newly completed RFCs: - RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS), Russ Housley, July 2003. - RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), Jim Schaad, July 2003. Reported that four I-Ds were approved and were now in the RFC Editor's Queue: - draft-ietf-smime-camellia-05 - draft-ietf-smime-symkeydist-09 - draft-ietf-smime-x400wrap-09 - draft-ietf-smime-x400transport-09 WG Last Call coming up again on: - draft-ietf-smime-rfc2632bis-04 (Son-of-CERT) - draft-ietf-smime-rfc2633bis-06 (Son-of-MSG) - draft-ietf-smime-examples-12 Up and coming drafts include: - draft-ietf-smime-cms-rsa-kem-01 - draft-ietf-smime-gost-00 New draft coming in soon: - draft-park-cms-seed-00 Completed milestones - Submittted x400wrap and x400transport drafts Open Milestones - Complete rfc2632bis and rfc2633bis - Complete examples draft - Develop draft on RSA PSS algorithm Longer Term - WG Last Call on RSA KEM - Submit RSA KEM - Final S/MIME version 3.1 interoperability matrix New Milestones - SEED - GOST EXAMPLES Paul Hoffman reported on the update to the CMS and ESS Examples draft. He noted that major revision was performed since Vienna. Essentially we admitted that we were in denial about a lot of the examples, and so rethought the scope so that it took at least two working implementations to include the case. Thus many examples were deleted. There are still some outstanding comments from Jim Schaad noting some bugs in the code. These should be resolved shortly. He noted that comments are still welcome. At least one comment outstanding. MSGbis and CERTbis Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts. He noted numerous changes from Jim Schaad (mostly editorial) had been integrated into the document. He noted that he still needs to clear up the "I-D Nits" issues (i.e., splitting references, etc.). He also noted that he is waiting for a secondary validation of hex dump. Jim Schaad is looking at this, but additional comments from others would be helpful. He noted that there was a new issue on definition of smimeCapabilities attribute values for the RC2 algorithm. It is not clear that these are defined anywhere. Ideally, we would like to have this elsewhere, but since it's kind of an afterthought we're going to have to squeeze it into MSG. Another new issue that has been discussed on the list is the guidance text on selection encryption algorithm. There was some obsolete language that dealt with weaker algorithms. Ramsdell indicated that he was revising text to update the decision tree to lead you instead to 3DES. Another new issue was clarification of the semantics of the smime-type subtype. The smime-type is indicated an attribute on the Content-Type MIME header. Current values defined in MSG include signed-data, enveloped-data, compressed-data, and certs- only. The question is, what is the right way to use this. - As a hint for IMAP? - As a content hint for processing? Ramsdell stated that he believed this should really reflect the outermost wrapper that must first be processed. Chris Bonatti stated that he didn't have an answer to this question, but pointed out that the x400wrap and x400transport drafts added some new values of smime-type for signed-x400 and encrypted-x400. While these clearly address more than just the outer wrapper, they distinguish a different service and message spec than S/MIME per se so there is some value. Indicating that he was an e-mail implementer, DABOO stated that he does not want to have to decode the entire content to know what kind of visual indicator to present, but he does not think that these two things are separate. Jim Schaad indicated that what brought this issue up is the ambiguity of signed receipts. In the instance of a signed- receipt that is also encrypted, which smime-type value should be used: the signed-receipt (defined in RFC 2634) or encrypted-data (as per the MSG spec)? Somebody (Blake?) noted that they have the same issue with the SIP WG, in that they want to easily identify data that contains SIP so that they can further process them. The chairman noted that he was not sure whether the Application Area should be consulted before deciding this matter. The WG tentatively agreed that the strawman solution is that smime-type is more a display hint than a processing hint, and that we will clarify this in the document. More discussion on the list is possible. Ramsdell noted that there is a PKIX issue that may require clarifications to the language regarding the subjectKeyIdentifier (SKI), and that he is not clear what the outcome should be. The problem is that use of the SKI to identify certificates is not sufficiently unique by itself. The reason for this seems to be that some implementations may issue crappy SKIs that are short, locally incremented identifiers. We need to add language to clarify that certificate processing when identified with SKI should: - Be prepared for matching multiple certificates; - Be prepared for some of those candidate certificates to fail. This would help implementations to bullet-proof against failing in what is a predictable scenario. Russ Housley, the Security Area Director, stated that he agreed with most of this, but indicated that we should preface this new text with the statement that if the recommendations of RFC 3280 are followed (i.e., SKI is the hash of the public key) then the overlap of these identifiers is possible but unlikely. This text is required mainly because that recommendation is a SHOULD instead of a MUST. Ramsdell also indicated that he had made several minor updates to the CERTbis document. He reported that he has added differences since 3.0 certificate profile to the document. He has also added credits and minor editorial fixes. PSS STATUS Jim Schaad reported that he has finished the edits of the PKIX version of PSS. This S/MIME PSS draft should be completed shortly. He also indicated that the Interoperability Matrix entries for CMS and CMSALG are finished. He still needs to do some editorial work to clean up the document. The ESSbis issue is still alive, but there has been no recent movement. KEM STATUS The Chairman reported speaking to Burt Kaliski of RSA, and noted that the KEM draft is temporarily stalled. The KEM draft is based on ANSI X9.44, which has not yet stabilized its ASN.1 syntax. The KEM draft cannot progress to RFC status until relevant X9.44 areas are stabilized. GOST STATUS The Chairman reported that the GOST draft is being updated and will be posted after the meeting. The new draft will add normative references to CMS and Russian law. He noted there are still some additional comments that need to be taken care of. Normative reference to CPALGS is a problem. The GOST algorithm needs to be described in an international standard, national standard, or RFC. An informational RFC would be easiest. Russ Housley stated that he thinks they are aiming to provide such an informative RFC for the Seoul meeting. Paul Hoffman pointed out that making it an RFC makes things a lot easier than the alternatives. Ramsdell and Housley agreed. Another issue is ASN.1 modules. The -00 draft uses the X.680 version of ASN.1, and needs to switch to X.208-88 to align with the rest of S/MIME. There are also too many modules in the draft. There were six modules in the -00 version, and will be 5 in -01, but they can still be further merged. SEED STATUS Jongwook Park from KISA gave a presentation introducing the SEED algorithm. He noted that SEED is based on a Feistel structure with 16 rounds. It has a 128-bit blocksize, and employs a 128-bit key. He proposed publishing the SEED algorithm description as an informational RFC prior to the Seoul meeting. All the documentation is available now from http://www.kisa.or.kr/seed/index.html. He invited comments from the WG. Park also noted that we should watch for feedback from ISO/IEC JTC1 SC27. The Chairman asked whether SEED was currently being considered by ISO. Park indicated that it was. He noted that he does not attend the ISO meetings, but some of his colleagues do. Ramsdell asked whether ISO has assigned OIDs for the algorithm. Park indicated that they have not. He stated that they were examining the strength of the algorithm, but there had been no results yet. Russ Housley asked whether SEED was the Korean national algorithm. Park responded that SEED was mandatory in Korea.