LAMPS Session at IETF 96
Charlottenburg I Room
Friday, 12:20 - 13:20

LAMPS WG Agenda

0)  Minute Taker, Jabber Scribe, Bluesheets

Rich Salz is the jabber scribe.
Yoav Nir taking notes for the minutes.

1)  Agenda Bash

No bashing.

2)  Status and open issues for draft-schaad-rfc5751-bis (Jim Schaad)

Extending S/MIME to use AEAD algorithms.  RFC 5751 is the S/MIME 3.2
Message Specification, what version number should we use for this?
Using S/MIME 3.5 for now.

Added AES-GCM as MUST implement.

Also plan to address the errata.  Are examples real?  Change title or
make them real examples.  Erratum from Peter Gutmann ASN.1 bytes don't
parse.

ASN.1 version of the module?  Jim thinks we should leave things alone.

Sean Leonard: we are updating the information object classes. Therefore,
the new ASN.1 module (2002+) should be updated too. However I think it
is okay for this rfc5751-bis document continue to use the 1988 syntax
normatively.

Update section 2.7 advice on algorithm selection.
Don't use level of encryption that is too low.

Header protection?  Probably not here.

Will also need to look at the new email address attribute for
EAI in certificates.

Jim will take these issues one-by-one to the list.

Any other issues? 

Stephen Farrell: We should only do changes that implementations are
likely to follow; not just stuff we like.  Jim agrees.

Sean Leonard: EAI topic: I think we should update S/MIME to discuss
EAI.  We should also update S/MIME to talk about how the inner MIME
content, which is binary clean, can have UTF-8 headers, consistent
with EAI.  Question is, should there be smimeCapability OID for EAI
support and UTF-8 headers?

Jim: 822 headers need UTF-8 headers.

Alexey Melnikov: Yes, by using the message-global instead of the
rfc822 media type, you can.

Russ Housley: So you're saying that by changing message-rfc822 to
message-global we'll get it for free?

Alexey: Uhhm, maybe.

3)  Status and open issues for draft-melnikov-spasm-eai-addresses
    (Alexey Melnikov and Wei Chuang)
    
Wei presenting...

Design Choice: OtherName vs GeneralName.  OtherName less likely to
break existing code.  The smtputf8Name name constraint intentionally
excludes similar types, but would need a duplicate for the rfc822Name
name constraint.

Updates will take time: OpenSSL in a year.  Have not talked with CAs
yet.

Tero  Kivinen: Are there security issues with having too many forms?

Russ: all of the name forms bound to public key. 

Tero: Our identifier is an email address.  In other applications,
like IPsec, the form is not specified.

Russ: The certificates document covers that; it needs updating too.

Jim: Need to talk to people creating certificates.

Sean Leonard: Just an observation. It is strange that the ITU-T X.509
committee provides two extension points for extending GeneralName.
OtherName is the older one, therefore more likely to be widely
deployed.  OtherName is also more compatible with ASN.1-1988 syntax,
compared to "ellipsis".


4)  Open issues for draft-ietf-curdle-pkix
    (Simon Josefsson or Jim Schaad)
    
Jim presenting...

David Benjamin's proposal: assign three object identifiers for the 25519
curve and three object identifiers for the 448 curve: ECDH; EdDSA; and
EdDSA with pre-hash.

Sean Turner: As an author of RFC5480, I'm a-okay with David's proposal.
I never really liked the SECG stuff that got adopted in PKIX/SMIME ...

Sean Leonard: So you're saying OneAsymmetricKey.privateKey, which is an
OCTET STRING, contains ECPrivateKey, right?

Jim: No!

Sean Turner: So..... that came from OpenSSL I was just reflecting what
appeared to be reality.

*** A hum to recommend David Benjamin's proposal to the CURDLE WG was
unanimously accepted.

5)  WG document adoption

*** A hum for the LAMPS WG to adopt draft-schaad-rfc5751-bis was
unanimously to do so.

*** A hum for the LAMPS WG to adopt draft-melnikov-spasm-eai-addresses
was unanimously to do so.

6)  Wrap Up

Session closed at 13:02.