Minutes IETF106: lamps
minutes-106-lamps-00

LAMPS WG Minutes at IETF 106 in Singapore

0)  Minute Taker, Jabber Scribe, Bluesheets

1)  Agenda Bash

We need a few minutes for draft-turner-5480-ku-clarifications.
It was added to Section 4.

2)  Documents with the RFC Editor and IESG
    a)  draft-ietf-lamps-pkix-shake (Panos, Quynh)
    b)  draft-ietf-lamps-cms-shakes (Quynh, Panos)
    c)  draft-ietf-lamps-cms-hash-sig (Russ)
    d)  draft-ietf-lamps-cms-mix-with-psk (Russ)

None of these documents needed discussion.

3)  Active Working Group Documents
    a)  draft-ietf-lamps-header-protection-requirements (Bernie)

The problem statement: Headers cannot be protected in S/MIME since
version 3.1.

Integrated feedback: simplified requirements for header fields not to
include in clear text and added a new 'ecryption only' on receiving
side.

Open Issues:
- We are not addressing 'encryption only'
  --> No comments - this should be the conclusion on this point.

- Should a single format cover all protection levels. Opinions?
  >> DKG - if we only do signing or only do encryption we are missing
     something. We should not encourage people to use encrypted but not
     signing messages.
  >> Alexey - this requirement was about _not_ having multiple ways.
  --> So the issue is resolved; we keep the single format requirement.

- To which extent are we addressing Backward Compatibility? 
  >> Alexey - This solves two types of issues - once we make the choice
     on the protected header other things shall follow.
  >> DKG - what happens to legacy clients when they receive these
     messages?  I think it is important we address this.
  --> Issue still open

- Not many people have read the draft (two people)
  >> Alexey: What do you think we shall do with the requirement
     documents?
  >> Russ: I think the requirements are not helping us reach decisions,
     let's focus on providing solutions.  Find the balance so that
     everyone is equally unhappy.
  
- How do we deal with rendering at receiving side of "Weird artifacts"?
  How do we solve problems that might look like an empty messages with
  an attachment or attachments cannot be opened?
  - We can fix broken implementations instead of deploying a
    "work-around" (memory hole). More research needed. If we go with
    the work-around, we might introduce other weird artifacts (e.g.,
    because of MIME libraries).

Open Discussion:
 >> DKG - Three people read that draft - all headers are in the crypto
    message. However the legacy display part is there for legacy support
    (backward compatibility - not for being treated "specially" by the
    receiving client that does not know about the protected headers.
    We are looking for more feedback on this.  We welcome additional
    contributors for the draft.
  >> Alexey - It seems we need to analyze the impact of the legacy
     displays.  How difficult are both approaches for the receiving
     side?
  >> Russ - We might use a survey-monkey to get feedback... 
  >> DKG - Maybe people can contribute with screenshot to the ML.
  >> Alexey - I can generate messages, and people can provide feedback
     to see if their client(s) crash, etc.
  >> DKG - The second question from Alexey is about the libraries.  We
     want test vectors and screen shots.  My question is "what is the
     question we are asking"?  Given the messages, we want to know what
     legacy clients receiving them will do.
  >> DKG - Also we need to look into the MIME libraries issues.
  >> Alexey - We have 5 or 6 implementation for S/MIME.
  >> Sean Turner - The implementatiom report back in the day, I think,
     mentions 9 implementations for CMS.
  >> Russ - We might need 6 different of messages.  How much time will
     it take to generate them?
  >> DKG - I can probably deliver on my idea by the end of the week.
  >> Alexey - I can probably do it next week.
  >> Russ - A couple of weeks is okay, but let's start
  --> Please sort out the logistics on the mail list

Next Steps:
  - Close open isssues, confirm the set of requirements; reach out to
    to implementers.

4)  Documents related to the proposed re-charter
    a)  draft-brockhaus-lamps-lightweight-cmp-profile (Hendrik)

Status:
- Exchanged EncryptedValue with EncryptedKey to enable the use of
  EnvelopedData.
- Added the support for legacy PKIs using a PKCS#10 request.
- Added possibility of central generation of a key pair to the
  certificate request.
- Completed the delayed enrollment case (async messages).
- Completed the specifications for the selected set of messages.

Next Steps:
- Integrate the WG feedback; deriving a different secret for the
  key-transport mechanism (PBMParameter). Maybe also some references
  for doing message transport that is file-based.
- Add new Key Usages in the profile with OIDs assigned by IANA.
- Add security considerations and editorial changes.

4)  Documents related to the proposed re-charter
    b)  draft-brockhaus-lamps-cmp-updates (Hendrik)

Status:
- Add new extended key usages.
- Complete the Encrypted values with regards to making use of encrypted
  keys and EnvelopedData.
- Minor generalizations such as the removal of the reqirement that all
  PKI messages contained in a nested message must be of the same type.
- There is no request id in "p10cr" transaction, but it is needed to
  open it to polling mechanism.
- We need to complete the ASN.1 modules and polish the document.
  >> Russ - Why do you need an OID for a CA?  We already have other ways
     to identify a CA in the certificate.
  >> Hendrik - You might want to sign CMP messages with a different key
     than the CA key.
  >> Sean - There is an OID for the RA in CMC, you might want to use it.

4)  Documents related to the proposed re-charter
    c)  draft-richardson-lamps-rfc7030est-clarify (Micheal)

Status:
- I put out the new document.
- I am seeking help once the WG is re-charted to allow adoption of it.
- Please read the document, especially if you have expertise on errata.

4)  Documents related to the proposed re-charter
    d)  draft-turner-5480-ku-clarifications (Sean)

Status:
- Section 3 of RFC 5480 is missing the description of values.
- This proposed update is only one page long.
- I am seeking adoption once the WG is re-charted to allow it.

4)  Documents related to the proposed re-charter
    e)  draft-housley-lamps-cms-update-alg-id-protect (Russ)

Status:
- We are nearly out of time, so I will skip the slides.
- The proposed update adds some protection against algorithm
  substitution attacks.
- I am seeking adoption once the WG is re-charted to allow it.

5)  Other Business (if time allows)
    a)  OCSPv2 (Max)

Time is up, so this presentation was not given.  However, the
slides are in the proceedings.