smime@conference.ietf.jabber.com - 2002/11/19
[17:34] %% mrose has arrived.
[17:38] %% awa has arrived.
[17:41] <awa> housley: meeting start; agenda bashing
[17:41] <awa> no changes to agenda
[17:42] <awa> housley: working group status
[17:43] <awa> have published 22 RFC's. 3 published since the last IETF: 3369, 3370, & 3394
[17:44] <awa> 3369:CMS; 3370:CMS algs; 3394 AES Key Wrap algorithm
[17:44] <awa> no documents in RFC editor's queue; 5 documents with IESG
[17:45] %% smb@research.att.com has arrived.
[17:45] <awa> advancement to draft standard: S/MIME is blocked until RFC 3280 progresses to Draft Standard
[17:47] <awa> Housley (for Hoffman): Examples document is close to ready for progression; want to add one more example of triple-wrap as described in ESS. There are a few lines that exceed 72 chars; that's the problem set.
[17:48] <awa> Ramsdell not here to discuss MSGbis and CERTbis
[17:48] <awa> Bonatti: S/MIME CMS-X.400 drafts: status and issues
[17:49] <awa> Both drafts are in -05 draft (put out early November; address IESG & WG comments)
[17:50] <awa> No outstanding issues in documents
[17:51] <awa> Will continue advancing these as standards track. Will deal with comments as they arrive. Will informally coordinate with ITU-T/ISO (Jim Craigie)
[17:52] <awa> Housley: strategy will be to publish docs as RFCs (at Proposed) when they're ready. If any ITU-T/ISO comments come up, they'll be dealt with before this moves to Draft. Not sure whether the IESG agrees with this philosophy.
[17:54] <awa> Schaad: Interoperability Matrix Update &AES Algorithm Update
[17:54] <awa> AES: must only use it with RSA-OAEP, not with RSA PKCS v1.5. Once this is published, expect an immediate last call from the chair.
[17:56] <awa> Interop matrix: CMS: 101 MUST statements (62%); 80 "features". CMS details: 2 to go in SignedData (AC's & unimplemented structs). EnvelopedData: 6 to go; 3 related to version number; 3 related to unimplemented algorithms & recipients
[17:57] <awa> Two CMS issues: MUST handle unimplemented alternatives in the CHOICE (RecipientInfo/SIgnerInfo) - No current known implementations support
[17:57] <awa> No MUST for detached content - is there one needed?
[18:04] <awa> Akihiro - Camilla Encryption Algorithm
[18:06] <awa> use of Camellia encryption algorithm in CMS. 128 bit block cipher; same block/key sizes as AES; royalty free licensing; can be implemented in low power/compact hardware
[18:07] <awa> 192-bit and 256-bit operations take 1.3 times as long as 128-bit operations
[18:08] <awa> can be implemented in 6.37 kilo-gates
[18:09] <awa> Content encryption: three different key sizes (128, 192, 256); CBC mode only; Parameter field must have IV; plain text padded before encrypt by number of appended octets
[18:10] <awa> key wrap identical to AES (take section 2.2.1 of RFC3394; replace AES with Camellia & that tells you how to do it). OID parameter field must be NULL
[18:11] <awa> Home page: http://info.isl.ntt.co.jp/camellia
[18:11] <awa> The goal is to make this an Informational RFC
[18:11] <awa> Housley: has anyone read the Camellia draft yet? No response
[18:12] <awa> Housley, for Ramsdell: S/MIME CERT and MSG drafts
[18:12] %% stephenh has arrived.
[18:15] <awa> MSG Changes from -01: renamed cert-management smime-type back to certs-only (there was no reason to change it in the first place); inner binary encoding changes (harmonized between this and the X400 drafts - use a binary encoding for inner wraps in a triple-wrap; base64 on the outer wrap only to constrain bloat); message/rfc822 language (covers protecting the subject line in a message); CompressedData (P Guttman's work is now an RFC; refers to that)
[18:15] %% Blake Ramsdell has arrived.
[18:15] <awa> Compressed Data: only guidancde for compressing is to not compress encrypted data
[18:16] <awa> Housley: any issues not covered by these slides? No response. WG Last Call will begin as soon as the meeting ends tonight.
[18:17] <Blake Ramsdell> Well, glad I was here to help ;)
[18:17] <awa> CERT Changes from -01: stronger email address wording; nonREpudiation and digitalSignature key usage clarification
[18:17] <awa> Remaining work: more PKCS#1 v1.5 warnings; More Diffie-Hellman warnings; summary of changes
[18:19] <awa> We've done everything except SIP and SIPPING; that speaker is not here because of a meeting conflict.
[18:20] <awa> Housley: any other issues before we adjourn?
[18:22] <awa> Housley: why is the HMAC key-wrap draft stuck in the IESG?
[18:22] <awa> Schiller: IESG is not sure this is an appropriate document for Informational; they think it should be Proposed Standard? What does the WG think?
[18:22] <awa> Housley: all the other algorithm documents are Informational; consistency is good.
[18:23] %% stephenh has left.
[18:24] <awa> Schiller: the problem is that we've used Informational for algorithms, particularly when they're not developed here. Recently, somebody pointed out that RFC 2026 says that a document on the standards track can't contain a normative reference to an Informational Document. (You can put a normative reference to somebody else's document, but not to an IETF document that's lower in the hierarchy.)
[18:25] <awa> Housley: fix it.
[18:25] <awa> Schiller: we're working on it. BCP is considered the same level as Full Standard (Informational is at the bottom of the hierarchy), so maybe make all the algorithm documents BCP's.
[18:27] <awa> Jeff's proposal is to use the variance procedure from 2026 and try to get the situation resolved this way.
[18:29] <awa> Bellovin: it's easy to make that argument when it's an external standard that we're just documenting. It's much harder to argue for a variance when it's an internally-developed document. The fastest way out for the HMAC-AES key wrap document is to make it Proposed Standard
[18:30] <awa> Schiller: will the WG grant him the authority to make this a Proposed Standard if it appears that the document will be stuck for a long time as Informational? Housley: any objection? No - Jeff will try to get the document published as Informational; if that looks like it won't work, he'll just make it Proposed Standard and clear the logjam that way.
[18:30] <awa> meeting adjourned.
[18:30] %% awa has left.
[18:31] %% Blake Ramsdell has left.
[18:32] %% smb@research.att.com has left.
[18:52] %% mrose has left.
[19:10] %% enger has arrived.
[19:11] %% enger has left.
[19:29] %% ed has arrived.
[19:29] %% ed has left.