From nobody Mon May 7 06:51:59 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234A6124235 for ; Mon, 7 May 2018 06:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICf6OwB93azE for ; Mon, 7 May 2018 06:51:55 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119C6120227 for ; Mon, 7 May 2018 06:51:55 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id i14-v6so25686375wre.2 for ; Mon, 07 May 2018 06:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ySo5N1/IbF/+lHe9+hZ+JvahJq2rwDwoRciJ8JyR3XU=; b=KKvbKb6EZMFzBP6gaxTbOC7/kjSPSJq8lbrCq07vFagCBkukIveVnqQHuduBmLEokh 5zl7jJCaGieh73920IAdU9+WR+O1ssJysTM0NnRvmMBjQYq/FLUOnhk30eTLBOUcWxmC TK0sJaEC2cIdAcGWVYhiyEz58qRuAXLNaLDQ3PlFB7Eom9BUlcuDIetrosHhWJuacW8e ERy624j1qu1ImpkNSp61iKsfW/ncfChMIM9c+ie93kiZBbWE+na31C1cwx3ZK9mW6h/z 3DKnBaQ5fW+Ig/6scnSQaN85V5dltEeIBuYB4ZATka46y1Mbht5NtQcFxLhw2rGzKD8t VIZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ySo5N1/IbF/+lHe9+hZ+JvahJq2rwDwoRciJ8JyR3XU=; b=rGNcj5w8gMHEsDxaUhH2eoYd2cvLTYOK66kZFC1Ac+jXHnKLTqtWn3DrBgtnBRZBeR U0RV7S2P0hVLUZEHRx33tQngUJj4yKmCEeJI64IJ2RmnogkYhSHq2E7sSzv70h7lMjYU F1i4iG++p8Wy626GIdxbcIlPQF87pgtBZFabNLqoIiQn1/RTj023AzhF5myjpF+7+8yb bjyp5S5k4LZYgY8nxPUAHzdK8jOzPh/Z4+6C3nkkXf6ZaLk8LFRJ7rlZRLtQwWntudWb PF58mfHEMWLtJEt2vc265bY/rHgSEIinHLyMxzJkRk62ojhlhnQHTlE6P84XZclQUCq5 XuCg== X-Gm-Message-State: ALQs6tB0a/1UtnAjMCMS3Rt/sOiEU9D5K2GkE5dIKtysBRmxlFx5LuWo 2RV/Kn141IPYcMxAgmDmcioFhwVCLFeChcoakMfUSw== X-Google-Smtp-Source: AB8JxZpds0MttjRFmNd3ilx48jEniUO9B2W5w3nhsbgkl0ePBb4kqogu5zQp4drNjczBlW8tPmBqAM1kX8tPDanR8S4= X-Received: by 2002:adf:e642:: with SMTP id b2-v6mr27881890wrn.172.1525701113385; Mon, 07 May 2018 06:51:53 -0700 (PDT) MIME-Version: 1.0 From: Nikos Mavrogiannopoulos Date: Mon, 07 May 2018 13:51:42 +0000 Message-ID: To: secdispatch@ietf.org, David Woodhouse Cc: kaduk@mit.edu Content-Type: multipart/alternative; boundary="000000000000e59880056b9df878" Archived-At: Subject: [Secdispatch] publishing PKCS#12/PKCS#5 clarification is indiv. draft X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 13:51:57 -0000 --000000000000e59880056b9df878 Content-Type: text/plain; charset="UTF-8" Background: PKCS#8 (rfc8018) and PKCS#12 (rfc7292) are used to encrypt keys and certificates with a password. Both however do not define how a password should be encoded other than referring to the ambiguous UTF-8 or BMPString encodings. In particular PKCS#8 utilizes PKCS#5 for converting a password to an encryption key, and PKCS#5 requires a password to be in UTF-8. For PKCS#12, a password is input in UTF-16 format (mentioned as BMPString in the document) in some preset schemes, but uses UTF-8 for newer schemes like AES via PKCS#5. Thus as UTF-8 (and UTF-16) are ambiguous the same internationalized string may have multiple representations. There are some guidelines (by a different WG) in RFC7613 to prepare a unicode string for a password, but they are not used by the documents above. The proposed draft, clarifies several aspects of the PKCS#12 and PKCS#5 documents with regards to internationalized strings, and proposes a well defined encoding for passwords in that context based on RFC7613. I'd like to have AD sponsorship for this draft. The draft (PKCS#5/PKCS#12 clarification on internationalized passwords): https://datatracker.ietf.org/doc/draft-mavrogiannopoulos-pkcs5-passwords/ Previous discussion on saag mailing list: https://mailarchive.ietf.org/arch/msg/saag/598CnK5rxOZ8qJY9W38gNNlIvvc regards, Nikos --000000000000e59880056b9df878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Background:
=C2=A0PKCS#8 (rfc8018) and PKCS#12 (rf= c7292) are used to encrypt keys and certificates with a password. Both howe= ver do not define how a password should be encoded other than referring to = the ambiguous UTF-8 or BMPString encodings. In particular
PKCS#8 utilize= s PKCS#5 for converting a password to an encryption key, and PKCS#5 require= s a password to be in UTF-8. For PKCS#12, a password is input in UTF-16 for= mat (mentioned as BMPString in the document) in some preset schemes, but us= es UTF-8 for newer schemes like AES via PKCS#5.

Thus as UTF-8 (and U= TF-16) are ambiguous the same internationalized string may have multiple re= presentations. There are some guidelines (by a different WG) in RFC7613 to = prepare a unicode string for a password, but they are not used by the docum= ents above.

The proposed draft, clarifies several aspects of t= he PKCS#12 and PKCS#5 documents with regards to internationalized strings, = and proposes a well defined encoding for passwords in that context based on= RFC7613.

I'd like to have AD sponsorship for th= is draft.

The draft (PKCS#5/PKCS#12 clarification on inte= rnationalized passwords):
https://datatracker.ietf.or= g/doc/draft-mavrogiannopoulos-pkcs5-passwords/

Previous discussi= on on saag mailing list:
https://mailarchive.ietf.org/a= rch/msg/saag/598CnK5rxOZ8qJY9W38gNNlIvvc

regards,
=
Nikos

--000000000000e59880056b9df878-- From nobody Tue May 22 07:03:42 2018 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C44812EB48; Tue, 22 May 2018 07:03:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, secdispatch@ietf.org, kaduk@mit.edu, secdispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152699781297.31338.18383891014149986869.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 07:03:32 -0700 Archived-At: Subject: [Secdispatch] secdispatch - New Meeting Session Request for IETF 102 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:03:41 -0000 A new meeting session request has just been submitted by Roman Danyliw, a Chair of the secdispatch working group. --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Roman Danyliw Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: saag mls acme perc dots ace Second Priority: tls mile People who must be present: Eric Rescorla Roman Danyliw Richard Barnes Benjamin Kaduk Resources Requested: Special Requests: Ideally this session wouldn't conflict with any security area meetings; and would be early in the week. --------------------------------------------------------- From nobody Thu May 24 18:45:00 2018 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3744D12D777 for ; Thu, 24 May 2018 18:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4C9fqNg4h4P for ; Thu, 24 May 2018 18:44:56 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D9812D7F1 for ; Thu, 24 May 2018 18:44:56 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l1-v6so3231343oii.1 for ; Thu, 24 May 2018 18:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=FxPoO/V8BtzdEPjNXSzuHp6HN73SLYySvmR17ugq6Mo=; b=MHPXz00Gw9kIcL+ONqN/D4G8BbCAHaDEEPNm0TAbYbJVhF1QSn2SftRlXuIzyH28cM K4q3mhD+eeCxMwIM4ToLjsJxaCEKiW3YtSNbGfwZkuv91hF7U3kHFYcc0Dig5NA4cc1V Ek/QrRu2KPpa/wfXY0E7p9H3xROMRMcK98nSU2v091nZ74oe86KEpI8nA195uUnMpP/w nlkrlF89EKSDhlxfZjxE8okz9p5GYtTgw7sYzbX2G8oC9kJoL+JECJha6OhLQT0FGyFc LbBNMUpDJuRBCErvAzElABV5oNo/nZuAnODMPtc3upRlHqn7i81U9eZ+fe0KlpBX8cxI JIDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=FxPoO/V8BtzdEPjNXSzuHp6HN73SLYySvmR17ugq6Mo=; b=OpG879NNeLqHa99pv7EqmiCsokquQFbjA7vRwDXZyvHgMHgEy7NmuJUYMoOGdtN8kI Hg0yx1pBP2ugyMG/ey8npV1YUb3iizG7T15sFZntgSsyA+WnFYk2rnaalNtDPLXKkGQP hbnnZ1p26ZeP7ZY5+S3PKW3ab7voU1YWzLkWqpZobYivEEJlomh/03AXR8BFFNQsljNK hElvKdIoTtcErFEEJ+VWle7qROKwYwJ3FwpiiPRwPjvIQm5zDwIcfIA6jH0FG7HL46HF xgn9GDCzYGAzFlkJXNeBs8KCWCWLBb46ax/dvDMYN5z2IxGdz9h2sHyrefr3muUVwWDg K4Iw== X-Gm-Message-State: ALKqPwcnb4X6JUdobIskRsSNA9FgjmD2arrsVe8JkZA1O0VsIoIjCniG WyXkyQVCeqmpWc5H/ZaoDpVHi4tpuBdUOUmVt+qmcw== X-Google-Smtp-Source: ADUXVKJp+deDb2Jlswlw6OMEZQhxLRneoGLf3mcMSXnNKyKljvMCnBiVekQRt8sD1imbAzilbZT/QnZ0bZ6fg/qFA3w= X-Received: by 2002:aca:75cc:: with SMTP id q195-v6mr178930oic.319.1527212695092; Thu, 24 May 2018 18:44:55 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 2002:a9d:23:0:0:0:0:0 with HTTP; Thu, 24 May 2018 18:44:54 -0700 (PDT) From: Phillip Hallam-Baker Date: Thu, 24 May 2018 21:44:54 -0400 X-Google-Sender-Auth: BBXkmlcok8-5cQ6Rl8XPDzPynBU Message-ID: To: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000003005db056cfdea2a" Archived-At: Subject: [Secdispatch] DARE Message and Container formats X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 01:44:58 -0000 --0000000000003005db056cfdea2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BI have been developing a set of tools and data formats to support encryption and authentication of sequenced data. These build on the work in JSON and JOSE =E2=80=8Bbut make certain changes for reasons of efficiency a= nd/or simplicity. The text versions of the documents are to be found here: https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/ https://datatracker.ietf.org/doc/draft-hallambaker-dare-message/ https://datatracker.ietf.org/doc/draft-hallambaker-dare-container/ The HTML versions have diagrams (converted into data URLs so they are still single file objects) http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html http://mathmesh.com/Documents/draft-hallambaker-dare-message.html http://mathmesh.com/Documents/draft-hallambaker-dare-container.html The near term application for this work is to encrypt log files for GDPR compliance. An open source reference implementation is available on GitHub. https://github.com/hallambaker/Mathematical-Mesh The chief difference between this work and earlier work is that the formats are designed to support efficient encryption of incremental updates to an append only log. So if a server restarts, it can perform a new key agreement and keep on writing to the old log. Use of split decryption key (recryption) functionality is supported but not required. So in an enterprise environment log files might be encrypted to the site encryption key and individual system administrators granted access to specific log files on an as-needed basis by the recryption service. Individual messages posted to the container consist of a body and a series of optional headers which may also be encrypted. This feature allows a message subject line to be encrypted separately from the message body that it applies to. A key innovation in the container format is the use of bidirectional frames which allow the file to be read with equal efficiency in either the forward or reverse direction. The container may optionally be indexed enabling rapid random access. The container format also provides means for digest authentication including static, chained and Merkle tree modes [The astute will notice that this provides a functionality similar to one that rhymes with clock-train]. Thus the format may be used for applications such as an archive format where one signature can be used to validate all the files in the archive. The message format is designed for both signature and encryption. The message body is signed first and then encryption is applied to both the message body and the signature values. This approach demonstrates that the signer had actual knowledge of the message content that was signed, defeating certain message substitution attacks. I would like to seek AD Sponsorship of this work. --0000000000003005db056cfdea2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8BI have been developing a set of tools and data formats to support enc= ryption and authentication of sequenced data. These build on the work in JS= ON and JOSE =E2=80=8Bbut make certain changes for reasons of efficiency and= /or simplicity.

The text = versions of the documents are to be found here:

https:= //datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/
https://datatrac= ker.ietf.org/doc/draft-hallambaker-dare-container/


The HTML versions have diag= rams (converted into data URLs so they are still single file objects)
=

http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.ht= ml
http://mathmesh.com/Documen= ts/draft-hallambaker-dare-message.html
http://mathmesh.com/Documents/draft-hallambaker-dare-container.h= tml


= The near term application for this work is to encrypt log files for GDPR co= mpliance. An open source reference implementation is available on GitHub.



The chief difference between this work and e= arlier work is that the formats are designed to support efficient encryptio= n of incremental updates to an append only log. So if a server restarts, it= can perform a new key agreement and keep on writing to the old log.
<= div class=3D"gmail_default" style=3D"font-size:small">
Use of split decryption key (r= ecryption) functionality is supported but not required. So in an enterprise= environment log files might be encrypted to the site encryption key and in= dividual system administrators granted access to specific log files on an a= s-needed basis by the recryption service.=C2=A0

Individual messages posted to the container consist = of a body and a series of optional headers which may also be encrypted. Thi= s feature allows a message subject line to be encrypted separately from the= message body that it applies to.


A key innovation in the container format is the use of bidirectional frame= s which allow the file to be read with equal efficiency in either the forwa= rd or reverse direction. The container may optionally be indexed enabling r= apid random access.

The c= ontainer format also provides means for digest authentication including sta= tic, chained and Merkle tree modes [The astute will notice that this provid= es a functionality similar to one that rhymes with clock-train]. Thus the f= ormat may be used for applications such as an archive format where one sign= ature can be used to validate all the files in the archive.

The message format is designed for both = signature and encryption. The message body is signed first and then encrypt= ion is applied to both the message body and the signature values. This appr= oach demonstrates that the signer had actual knowledge of the message conte= nt that was signed, defeating certain message substitution attacks.


I would like to seek AD Sponsorship of t= his work.
--0000000000003005db056cfdea2a--