[Spasm] Raw minutes from LAMPS meeting

[Yoav Nir <[e-mail]>]

LAMPS Meeting - IETF 96
Charlottenburg I room
Friday, 12:20 - 13:20

Agenda:
LAMPS WG Agenda

0)  Minute Taker, Jabber Scribe, Bluesheets

Began 12:21. Rsalz is the jabber scribe. Yoav taking minutes. Seen the Note Well; blue sheets going around.

1)  Agenda Bash

(12:24) - looking at the agenda. No bash

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

Extension to use AEAD algorithms in RFC 5751 (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification)
Added AES-GCM as MUST; pulled in errata
Which version of S/Mime? 3.5 for now.
Are example 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 table constraints/information object classes. Therefore, the new ASN.1 module (2002+) should be updated (at some point). However I think it's okay for this S/MIMEbis document to list the 88 syntax normatively.
Additional security considerations
Algorithm requirements
Update section 2.7 advice on algorithm selection
Don't use level of encryption that is too low.
Header protection?  Probably not here.
Look at the new email address attribute 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 (and has ideas that are not realistic)
Sean Leonard: eai topic: I think we should update S/MIME to discuss eai stuff. ALSO, should update S/MIME to talk about how the inner MIME content (which is binary clean) has [ought to have] UTF-8 headers, consistent with EAI. Question is, should there be smimeCapability OID for eai (UTF-8 headers)? think about it...
Jim: 822 headers need UTF-8 headers
Alexey: yes, but message-global not rfc822, but you can still construct
Russ: 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 and Wei)
https://tools.ietf.org/html/draft-melnikov-spasm-eai-addresses <https://tools.ietf.org/html/draft-melnikov-spasm-eai-addresses>
(12:37) Wei presenting
OtherName vs GeneralName
smtputf8Name name constraint intentionally excludes similar types
Updates will take time: OpenSSL in a year. Have not talked yet with CAs.
Tero: security issues with having too many forms? 
Russ: all forms bound to key. 
Tero: our identifier is email address (IPsec for example). The form is not specified. 
Russ: that goes in the certs document that needs updating
Jim: Need to talk to people creating certificates
Sean Leonard: just an observation. It is strange that X.509 (ITU-T committee) provides *two* extension points for extending GeneralName. Historically, otherName (with an open type / table constraint based on OID) is the older one, therefore more likely to be widely deployed. otherName is also more compatible with ASN.1-88 syntax, compared to "ellipsis".


4)  Open issues for draft-ietf-curdle-pkix (Simon or Jim)
https://tools.ietf.org/html/draft-ietf-curdle-pkix <https://tools.ietf.org/html/draft-ietf-curdle-pkix>
(12:47) Jim presenting
David Benjamin's proposal: 3 OIDs per curve: ECDH (25519 & 448); EdDSA (no PH); EdDSAph
Sean Turner: As an author of RFC5480, I'm a-okay with DavidBen's proposal.  I never really liked the SECG stuff that got adopted in PKIX/SMIME ...
Sean Leonard: so you're saying OneAsymmetricKey.privateKey (OCTET STRING) contains ECPrivateKey ...that's the proposal, 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 was unanimously yes.

5)  WG document adoption

Do we want to adopt Jim's draft on the message spec: draft-schaad-rfc5751-bis
*** Unanimously yes (also on Jabber)

Do we want to adopy Wei's draft on internationalized email addresses: draft-melnikov-spasm-eai-addresses
*** Unanimously yes

6)  Wrap Up

(13:02) wrapped up