From nobody Mon Jun 7 05:51:51 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F573A14AC for ; Mon, 7 Jun 2021 05:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 0mrbdcMJWTgl for ; Mon, 7 Jun 2021 05:51:43 -0700 (PDT) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) (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 0AC083A14A2 for ; Mon, 7 Jun 2021 05:51:42 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id g142so5418447ybf.9 for ; Mon, 07 Jun 2021 05:51:42 -0700 (PDT) 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; bh=ka/7/+M/iDsu51gto3/eiXlYeFMP8tYa3RQm9tW9ETk=; b=rRonuz1kNqrlllZXZzylUWddWtaAC+KO4jJYrVFy1OHgJToMQlabdWOdPAcycf/ezJ VJ/agguCysJ8SrA+X9JG5n8xK4VLlTpY+cdpqIy+fFKKt7lRKmrLma4QT+DcbNCWoLkm G7rT3zcSGmTFEMUAkeX6fXJW9hObThkwZQV0TE7XmQHZhrgQi5cDkv+DHdgKz4mzI6bC qdFLolx9Zx2FdmJ/OoDcuj7NcFBdUJT5qjzCbAB/afITdE8/MKcXGxzCNTq2kq/fR+QO BE0/TS+621O5zJYEVoHu4rYVJ1PGxD4emRURWikMPdyTuhITjIXGzy/38vUV6Er8btO9 J+pg== X-Gm-Message-State: AOAM5312w1GkDYc+rNlCzVMy+RNe/yo3D2Z64Wku0l7cYbVq/eniioUB 3l0tV+XiyeqC8EILq9h0DZjzD/HA4Q5tLX78Mhlffzfg6mNabA== X-Google-Smtp-Source: ABdhPJxkFPDH7FstnW6s24oETNXEhUcxJI9zSAfmlUKMDGvsBFpMhzvn7J1T4QlHynS4VDxX3h1k2IzFiNNKdMA8xyA= X-Received: by 2002:a25:850b:: with SMTP id w11mr22834104ybk.518.1623070301754; Mon, 07 Jun 2021 05:51:41 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Mon, 7 Jun 2021 08:51:30 -0400 Message-ID: To: IETF SAAG , IRTF CFRG Content-Type: multipart/alternative; boundary="000000000000c8190305c42c8068" Archived-At: Subject: [saag] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 12:51:48 -0000 --000000000000c8190305c42c8068 Content-Type: text/plain; charset="UTF-8" Raising this in SAAG because this raises a policy issue and CFRG because that is where the policy should be enforced. It is also relevant to LAMPS but trying to avoid cross posting as everyone on the LAMPS list is likely on SAAG. rfc7253 specifies OCB mode. But there is no OID specified to use OCB with CMS, nor are there identifiers for use with JOSE. This is problematic to say the least. If an algorithm is worth publishing as an RFC, there should be definitive identifiers for general purpose packaging formats specified in that RFC. I would like to propose that in future assignment of relevant OIDs and JOSE identifiers be considered a requirement for similar work. If a spec for a symmetric mode isn't sufficiently specified to enable interoperable implementation in CMS and JOSE, it is not sufficiently specified to be an RFC. This would not cover TLS, IPSEC etc. since they have rather different considerations. Algorithms are curated and selected as suites for TLS for a start. I am not a fan of having multiple registries for specifying identifiers for algorithms. In fact if I had my way, there would be a single IANA text registry because while we could write a spec for a cryptographic algorithm and call it SMTP, that would be silly. It seems to me that one registry for the ASN.1 identifiers and one for text based identifiers is sufficient for all reasonable purposes. To the extent that XML signature and encryption are still a thing, well why don't we just specify a generic URN scheme for IANA registries and have done. --000000000000c8190305c42c8068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Raising this= in SAAG because this raises a policy issue and CFRG because that is where = the policy should be enforced. It is also relevant to LAMPS but trying to a= void cross posting as everyone on the LAMPS list is likely on SAAG.


rfc7253 specifies OCB mode. But there is no O= ID specified to use OCB with CMS, nor are there identifiers for use with JO= SE.

This is problematic to say the least. If an algorithm is worth publis= hing as an RFC, there should be definitive identifiers for general purpose = packaging formats specified in that RFC.
=
I would like to propose that in futu= re assignment of relevant OIDs and JOSE identifiers be considered a require= ment for similar work. If a spec for a symmetric mode isn't sufficientl= y specified to enable interoperable implementation in CMS and JOSE, it is n= ot sufficiently specified to be an RFC.
<= br>
This would not cover TLS, IPSEC etc. = since they have rather different considerations. Algorithms are curated and= selected as suites for TLS for a start.=C2=A0

I am not a fan of having multi= ple registries for specifying identifiers for algorithms. In fact if I had = my way, there would be a single IANA text registry because while we could w= rite a spec for a cryptographic algorithm and call it SMTP, that would be s= illy.=C2=A0

It seems to me that one registry for the ASN.1 identifiers and on= e for text based identifiers is sufficient for all reasonable purposes. To = the extent that XML signature and encryption are still a thing, well why do= n't we just specify a generic URN scheme for IANA registries and have d= one.
--000000000000c8190305c42c8068-- From nobody Mon Jun 7 06:46:02 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367873A16C3; Mon, 7 Jun 2021 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 LU4IBWZHs-vi; Mon, 7 Jun 2021 06:45:55 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9CB3A16BB; Mon, 7 Jun 2021 06:45:55 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 157DdHew012853; Mon, 7 Jun 2021 14:45:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lwstTNgPW3zk/qklsYN50mdNcMjB0ESn7LrvyhbogoY=; b=UnwNOh8qEbR2WRuzrEZ/qB5q8LX/NC94//TPO0IbZFtMsJXXGcVgOZBImPAuI23DJqsq Nm3v+ZAcWu927Fj3XP4QDzKU2xnzE/A0tuLp6S6zIej3McidNh6IBvCtwYGTRMwoP4IY Xo16gudpoChEds275bzy1rsjUmK5OdaRJIqu9BEL65VXIRTSX4DPpd0exHvSwAYi4gRr tGa2QbjIB9HUNcsvNhy46V7/6mKxF+TBK45CAQ/ZA5yD0t1J09BtDIWFBc9CXYGsykBN fEaCQYyqXDJo5OpWhYKF2x4Zrq40I4UKm7D+mlxJnO+za3uGEfcFYnpZPyhcHikxQHz6 FA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 390wuj2sra-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jun 2021 14:45:51 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 157DXuIV010379; Mon, 7 Jun 2021 09:45:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 390pnxp00p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Jun 2021 09:45:50 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 7 Jun 2021 08:44:50 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.018; Mon, 7 Jun 2021 08:44:50 -0500 From: "Salz, Rich" To: Phillip Hallam-Baker , IETF SAAG , IRTF CFRG Thread-Topic: [CFRG] OCB does not have an OID specified, that is a general problem Thread-Index: AQHXW5vIYrzAnqRp0kOCcj8BfVyMUKsIoGWA Date: Mon, 7 Jun 2021 13:44:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_B73FB6B13EFC4AEA9A998C047F478944akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-07_10:2021-06-04, 2021-06-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=907 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106070100 X-Proofpoint-GUID: QCcxwm7AljlQKIoM3wPQtIkx1fqKVzFy X-Proofpoint-ORIG-GUID: QCcxwm7AljlQKIoM3wPQtIkx1fqKVzFy X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-07_10:2021-06-04, 2021-06-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxscore=0 adultscore=0 clxscore=1011 priorityscore=1501 malwarescore=0 phishscore=0 lowpriorityscore=0 impostorscore=0 mlxlogscore=828 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106070101 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 13:46:00 -0000 --_000_B73FB6B13EFC4AEA9A998C047F478944akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgcmZjNzI1MyBzcGVjaWZpZXMgT0NCIG1vZGUuIEJ1dCB0aGVyZSBpcyBubyBPSUQgc3Bl Y2lmaWVkIHRvIHVzZSBPQ0Igd2l0aCBDTVMsIG5vciBhcmUgdGhlcmUgaWRlbnRpZmllcnMgZm9y IHVzZSB3aXRoIEpPU0UuDQoNCkZvciB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgYSByZXF1ZXN0IHRv IHRoZSBJQU5BIGV4cGVydCB3aWxsIGdldCBhbiBPSUQuICAoSGXigJlzIGEgY28tY2hhaXIgb2Yg TEFNUFMgOikNCg0KDQogICogICBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGF0IGluIGZ1dHVy ZSBhc3NpZ25tZW50IG9mIHJlbGV2YW50IE9JRHMgYW5kIEpPU0UgaWRlbnRpZmllcnMgYmUgY29u c2lkZXJlZCBhIHJlcXVpcmVtZW50IGZvciBzaW1pbGFyIHdvcmsuIElmIGEgc3BlYyBmb3IgYSBz eW1tZXRyaWMgbW9kZSBpc24ndCBzdWZmaWNpZW50bHkgc3BlY2lmaWVkIHRvIGVuYWJsZSBpbnRl cm9wZXJhYmxlIGltcGxlbWVudGF0aW9uIGluIENNUyBhbmQgSk9TRSwgaXQgaXMgbm90IHN1ZmZp Y2llbnRseSBzcGVjaWZpZWQgdG8gYmUgYW4gUkZDLg0KDQpUaGF04oCZcyBhIHJlYXNvbmFibGUg dGhpbmcgdG8gYXNrIGZvciwgYW5kIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGNhdWdodCBieSBT RUNESVIgb3IgQUQgcmV2aWV3Lg0KDQo= --_000_B73FB6B13EFC4AEA9A998C047F478944akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <62534BC79D7EDE4CA599BD471FC4E240@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIyOTg0NzYwODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NTAyMDgyODQgLTI5MzY3NzY2NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjExOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+cmZjNzI1MyBzcGVjaWZpZXMgT0NCIG1vZGUuIEJ1dCB0aGVyZSBpcyBubyBPSUQg c3BlY2lmaWVkIHRvIHVzZSBPQ0Igd2l0aCBDTVMsIG5vciBhcmUgdGhlcmUgaWRlbnRpZmllcnMg Zm9yIHVzZSB3aXRoIEpPU0UuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgYSByZXF1ZXN0IHRvIHRoZSBJQU5BIGV4 cGVydCB3aWxsIGdldCBhbiBPSUQuJm5ic3A7IChIZeKAmXMgYSBjby1jaGFpciBvZiBMQU1QUyA6 KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCBpbiBm dXR1cmUgYXNzaWdubWVudCBvZiByZWxldmFudCBPSURzIGFuZCBKT1NFIGlkZW50aWZpZXJzIGJl IGNvbnNpZGVyZWQgYSByZXF1aXJlbWVudCBmb3Igc2ltaWxhciB3b3JrLiBJZiBhIHNwZWMgZm9y IGEgc3ltbWV0cmljIG1vZGUgaXNuJ3Qgc3VmZmljaWVudGx5DQogc3BlY2lmaWVkIHRvIGVuYWJs ZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9uIGluIENNUyBhbmQgSk9TRSwgaXQgaXMgbm90 IHN1ZmZpY2llbnRseSBzcGVjaWZpZWQgdG8gYmUgYW4gUkZDLjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF04oCZcyBhIHJlYXNvbmFibGUgdGhpbmcgdG8g YXNrIGZvciwgYW5kIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGNhdWdodCBieSBTRUNESVIgb3Ig QUQgcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_B73FB6B13EFC4AEA9A998C047F478944akamaicom_-- From nobody Mon Jun 7 06:53:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64AC3A1723; Mon, 7 Jun 2021 06:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 2ukLK7EjrNf4; Mon, 7 Jun 2021 06:53:21 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3422E3A171A; Mon, 7 Jun 2021 06:53:20 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 157DrCM2011603; Mon, 7 Jun 2021 09:53:12 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 157DrCM2011603 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1623073993; bh=N0G/OoshoIVT+Cm11iKuNySh4hwvNUSPnwTxxt1TVQU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=GHDqm+T5XmXSDd0KHZ0PcROuz7L/lHqHNBxdmQoXe5J2BjozcN7z56z3Rwdcq2p44 aV8XXbKMmx2n+dTIhVIhonBdOWTdgVAerqg8TzISD5xNXLpHdeg1/UHTj5D47V/zSF Z5n+yNwXTjxC/kHoX2DBoOklKDAuiLm1Hle5uroY= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 157DrCbE029886; Mon, 7 Jun 2021 09:53:12 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Mon, 7 Jun 2021 09:53:11 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2242.008; Mon, 7 Jun 2021 09:53:11 -0400 From: Roman Danyliw To: "Salz, Rich" , Phillip Hallam-Baker , IETF SAAG , IRTF CFRG Thread-Topic: [CFRG] OCB does not have an OID specified, that is a general problem Thread-Index: AQHXW6N+a1Vrdzx3xU+eJBWSPnEszasIkDQQ Date: Mon, 7 Jun 2021 13:53:10 +0000 Message-ID: <773badc5fdc04c41a5ceea7ad4fe29fe@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.170] Content-Type: multipart/alternative; boundary="_000_773badc5fdc04c41a5ceea7ad4fe29fecertorg_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 13:53:26 -0000 --_000_773badc5fdc04c41a5ceea7ad4fe29fecertorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkZyb206IHNhYWcgPHNhYWctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFNh bHosIFJpY2gNClNlbnQ6IE1vbmRheSwgSnVuZSA3LCAyMDIxIDk6NDUgQU0NClRvOiBQaGlsbGlw IEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPjsgSUVURiBTQUFHIDxzYWFnQGll dGYub3JnPjsgSVJURiBDRlJHIDxjZnJnQGlydGYub3JnPg0KU3ViamVjdDogUmU6IFtzYWFnXSBb Q0ZSR10gT0NCIGRvZXMgbm90IGhhdmUgYW4gT0lEIHNwZWNpZmllZCwgdGhhdCBpcyBhIGdlbmVy YWwgcHJvYmxlbQ0KDQoNCiAgKiAgIHJmYzcyNTMgc3BlY2lmaWVzIE9DQiBtb2RlLiBCdXQgdGhl cmUgaXMgbm8gT0lEIHNwZWNpZmllZCB0byB1c2UgT0NCIHdpdGggQ01TLCBub3IgYXJlIHRoZXJl IGlkZW50aWZpZXJzIGZvciB1c2Ugd2l0aCBKT1NFLg0KDQpGb3IgdGhpcyBwYXJ0aWN1bGFyIGNh c2UsIGEgcmVxdWVzdCB0byB0aGUgSUFOQSBleHBlcnQgd2lsbCBnZXQgYW4gT0lELiAgKEhl4oCZ cyBhIGNvLWNoYWlyIG9mIExBTVBTIDopDQoNCg0KICAqICAgSSB3b3VsZCBsaWtlIHRvIHByb3Bv c2UgdGhhdCBpbiBmdXR1cmUgYXNzaWdubWVudCBvZiByZWxldmFudCBPSURzIGFuZCBKT1NFIGlk ZW50aWZpZXJzIGJlIGNvbnNpZGVyZWQgYSByZXF1aXJlbWVudCBmb3Igc2ltaWxhciB3b3JrLiBJ ZiBhIHNwZWMgZm9yIGEgc3ltbWV0cmljIG1vZGUgaXNuJ3Qgc3VmZmljaWVudGx5IHNwZWNpZmll ZCB0byBlbmFibGUgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbiBpbiBDTVMgYW5kIEpPU0Us IGl0IGlzIG5vdCBzdWZmaWNpZW50bHkgc3BlY2lmaWVkIHRvIGJlIGFuIFJGQy4NCg0KVGhhdOKA mXMgYSByZWFzb25hYmxlIHRoaW5nIHRvIGFzayBmb3IsIGFuZCBzb21ldGhpbmcgdGhhdCBjb3Vs ZCBiZSBjYXVnaHQgYnkgU0VDRElSIG9yIEFEIHJldmlldy4NCg0KW1JvbWFuXSBBZ3JlZWQgaW4g dGhlIGdlbmVyYWwgY2FzZSBmb3IgdGhlIElFVEYgc3RyZWFtLiAgRm9yIFJGQzcyNTMsIHRoaXMg cmV2aWV3IHdvdWxkIGhhdmUgYmVlbiBkdXJpbmcgSUVTRyBjb25mbGljdCByZXZpZXcgYmVjYXVz ZSB0aGF0IGRvY3VtZW50IHdhcyBJUlRGIHN0cmVhbSAod2hpY2ggZG9lc27igJl0IGhhdmUgYW4g U0VDRElSIHJldmlldywgQUQgcmV2aWV3IG9yIGV2ZW4gYW4gSUVTRyBiYWxsb3QpLg0KDQpSb21h bg0KDQo= --_000_773badc5fdc04c41a5ceea7ad4fe29fecertorg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MjI5ODQ3NjA4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo1MDIwODI4NCAtMjkzNjc3NjY0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTE7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1 ODUxODY2NDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjYxMDAzMzQ4NDt9DQpAbGlzdCBsMTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyDQoJe21zby1saXN0LWlkOjE5NjQzODU4Mjg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi00ODU2MTQ1MDY7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBzYWFnICZsdDtzYWFnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8 L2I+DQpTYWx6LCBSaWNoPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSA3LCAyMDIxIDk6 NDUgQU08YnI+DQo8Yj5Ubzo8L2I+IFBoaWxsaXAgSGFsbGFtLUJha2VyICZsdDtwaGlsbEBoYWxs YW1iYWtlci5jb20mZ3Q7OyBJRVRGIFNBQUcgJmx0O3NhYWdAaWV0Zi5vcmcmZ3Q7OyBJUlRGIENG UkcgJmx0O2NmcmdAaXJ0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2FhZ10g W0NGUkddIE9DQiBkb2VzIG5vdCBoYXZlIGFuIE9JRCBzcGVjaWZpZWQsIHRoYXQgaXMgYSBnZW5l cmFsIHByb2JsZW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5y ZmM3MjUzIHNwZWNpZmllcyBPQ0IgbW9kZS4gQnV0IHRoZXJlIGlzIG5vIE9JRCBzcGVjaWZpZWQg dG8gdXNlIE9DQiB3aXRoIENNUywgbm9yIGFyZSB0aGVyZSBpZGVudGlmaWVycyBmb3IgdXNlIHdp dGggSk9TRS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9y IHRoaXMgcGFydGljdWxhciBjYXNlLCBhIHJlcXVlc3QgdG8gdGhlIElBTkEgZXhwZXJ0IHdpbGwg Z2V0IGFuIE9JRC4mbmJzcDsgKEhl4oCZcyBhIGNvLWNoYWlyIG9mIExBTVBTIDopPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8zIj5JIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGF0IGluIGZ1dHVyZSBhc3Np Z25tZW50IG9mIHJlbGV2YW50IE9JRHMgYW5kIEpPU0UgaWRlbnRpZmllcnMgYmUgY29uc2lkZXJl ZCBhIHJlcXVpcmVtZW50IGZvciBzaW1pbGFyIHdvcmsuIElmIGEgc3BlYyBmb3IgYSBzeW1tZXRy aWMgbW9kZSBpc24ndCBzdWZmaWNpZW50bHkNCiBzcGVjaWZpZWQgdG8gZW5hYmxlIGludGVyb3Bl cmFibGUgaW1wbGVtZW50YXRpb24gaW4gQ01TIGFuZCBKT1NFLCBpdCBpcyBub3Qgc3VmZmljaWVu dGx5IHNwZWNpZmllZCB0byBiZSBhbiBSRkMuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIGEgcmVhc29uYWJsZSB0aGluZyB0byBhc2sgZm9yLCBh bmQgc29tZXRoaW5nIHRoYXQgY291bGQgYmUgY2F1Z2h0IGJ5IFNFQ0RJUiBvciBBRCByZXZpZXcu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltSb21hbl0gQWdyZWVkIGluIHRoZSBnZW5lcmFsIGNh c2UgZm9yIHRoZSBJRVRGIHN0cmVhbS4mbmJzcDsgRm9yIFJGQzcyNTMsIHRoaXMgcmV2aWV3IHdv dWxkIGhhdmUgYmVlbiBkdXJpbmcgSUVTRyBjb25mbGljdCByZXZpZXcgYmVjYXVzZSB0aGF0IGRv Y3VtZW50IHdhcyBJUlRGIHN0cmVhbSAod2hpY2ggZG9lc27igJl0IGhhdmUgYW4gU0VDRElSIHJl dmlldywgQUQgcmV2aWV3IG9yIGV2ZW4gYW4gSUVTRyBiYWxsb3QpLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Sb21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_773badc5fdc04c41a5ceea7ad4fe29fecertorg_-- From nobody Mon Jun 7 07:02:39 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FBE3A1791 for ; Mon, 7 Jun 2021 07:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FW_kq8ODfkUz for ; Mon, 7 Jun 2021 07:02:23 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 ABE2B3A176B for ; Mon, 7 Jun 2021 07:02:23 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id v206-20020a1cded70000b02901a586d3fa23so37819wmg.4 for ; Mon, 07 Jun 2021 07:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mwEvYBtid768Bgv7tfHrzsFiTZnRz7w4RSsj/vJ2K/Y=; b=GHjx2M1R49fFOqpT7KDnfZM4HZP9Ss6V+oE8bM59FzFV2QslHRzfKbLJc+mS3g57ZV BXLXggX5IgS1O055F8wzlKjVsYksuAK7/xzt2EWUsK/I6b2IVeXL+z2B4syk3FCRjIw8 8IvZhtFmZMxOQk6nhZk0UcHZK7+9mzK3KI0msT3Q2+z1cqO8KQbljwnANf7he5Req4Og K8/cUSjvencwoVrMQxYz+pf3QK639/Z3GHw/mN5Rqyt34xVN79b57noWuGOSKFjYW0WF 9zV5wXaoxXR6UkRvJIsNO805gHFms35wlgV++20XZpmFed7IuojQUWB2fiSh/jVgP/Sh wvOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mwEvYBtid768Bgv7tfHrzsFiTZnRz7w4RSsj/vJ2K/Y=; b=sT+bKVOio7B7hpo8gsEdybiMCskRAQI46Vy6w829JE7rJwVwGO/ws/Mlw7Hz1ENm0e P2Q1aUO/cEQWcsml3RCeRNWK4WXMOVTGzpFtGWfdtM9O9y5r/92aUnDxLalEMsXxM70j RiKSPLcE2w1quVMyEVmZ8qwg1ReR+dwQtYK8H9ja7j9gTfnR4bSpsy8SxyjKloE5ApQ+ c8mt/gbyku4MENigg2Up9FWIYkK+z45O/OBy8mGii//O5J2Afj8dHLDkLACQL4tLQzUB //HY2+CKu/unpaopgvnSY5AhDUX62AH2DdFGAu9cLKqhYeDH0K7LQsUf1ME26+HrFvNW PAvg== X-Gm-Message-State: AOAM532BVRG1RyiHSpMzS2QLqNn4JL/z6/pNqdCCcADceWZRgkziO64G qop65sOmxt77JjepehEBA2KxAxSEK0gy/A== X-Google-Smtp-Source: ABdhPJw2vhgA6kEorG8Q+3EzStJvmRixmf6ab8sLWsZmfpTfQg4DyDlwY1AwRXoWkWk/Am16jTqJ8Q== X-Received: by 2002:a05:600c:4282:: with SMTP id v2mr16904371wmc.18.1623074537024; Mon, 07 Jun 2021 07:02:17 -0700 (PDT) Received: from [10.0.0.6] (113.87.75.194.dyn.plus.net. [194.75.87.113]) by smtp.gmail.com with ESMTPSA id b26sm17391587wmj.25.2021.06.07.07.02.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jun 2021 07:02:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Neil Madden In-Reply-To: Date: Mon, 7 Jun 2021 15:02:14 +0100 Cc: IETF SAAG , IRTF CFRG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 14:02:38 -0000 Unless there is a compelling reason to do so, I=E2=80=99d prefer that = registering algorithm identifiers for JOSE be a manual (and rare) step. = JOSE provides no way for consumers to advertise which Encryption Methods = they support (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so = adding new options here can only harm interoperability. (This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D = - as these can be advertised in the JSON Web Key metadata). =E2=80=94 Neil > On 7 Jun 2021, at 13:51, Phillip Hallam-Baker = wrote: >=20 > Raising this in SAAG because this raises a policy issue and CFRG = because that is where the policy should be enforced. It is also relevant = to LAMPS but trying to avoid cross posting as everyone on the LAMPS list = is likely on SAAG. >=20 >=20 > rfc7253 specifies OCB mode. But there is no OID specified to use OCB = with CMS, nor are there identifiers for use with JOSE. >=20 > This is problematic to say the least. If an algorithm is worth = publishing as an RFC, there should be definitive identifiers for general = purpose packaging formats specified in that RFC. >=20 > I would like to propose that in future assignment of relevant OIDs and = JOSE identifiers be considered a requirement for similar work. If a spec = for a symmetric mode isn't sufficiently specified to enable = interoperable implementation in CMS and JOSE, it is not sufficiently = specified to be an RFC. >=20 > This would not cover TLS, IPSEC etc. since they have rather different = considerations. Algorithms are curated and selected as suites for TLS = for a start.=20 >=20 > I am not a fan of having multiple registries for specifying = identifiers for algorithms. In fact if I had my way, there would be a = single IANA text registry because while we could write a spec for a = cryptographic algorithm and call it SMTP, that would be silly.=20 >=20 > It seems to me that one registry for the ASN.1 identifiers and one for = text based identifiers is sufficient for all reasonable purposes. To the = extent that XML signature and encryption are still a thing, well why = don't we just specify a generic URN scheme for IANA registries and have = done. > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Jun 7 07:15:29 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489683A180F for ; Mon, 7 Jun 2021 07:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001] autolearn=no autolearn_force=no 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 QfjhJA7Z_aHd for ; Mon, 7 Jun 2021 07:15:19 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B1F3A1807 for ; Mon, 7 Jun 2021 07:15:19 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FzFkq6rgvz2xGd; Mon, 7 Jun 2021 16:15:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 7 Jun 2021 16:15:15 +0200 Cc: IRTF CFRG , IETF SAAG X-Mao-Original-Outgoing-Id: 644768115.547217-b5b2e53b0597b6ec54bbd024f8e6efdd Content-Transfer-Encoding: quoted-printable Message-Id: <21478552-8308-4DB9-AA37-5607549E1C91@tzi.org> References: To: Neil Madden X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 14:15:28 -0000 On 2021-06-07, at 16:02, Neil Madden wrote: >=20 > Unless there is a compelling reason to do so, I=E2=80=99d prefer that = registering algorithm identifiers for JOSE be a manual (and rare) step. = JOSE provides no way for consumers to advertise which Encryption Methods = they support (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so = adding new options here can only harm interoperability. ... and for COSE, I don=E2=80=99t think there is such a constraint, so = algorithm registration should be handled together with any OID checking. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 7 07:34:29 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A0C3A18A4 for ; Mon, 7 Jun 2021 07:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0uv1Sc-YhD_r for ; Mon, 7 Jun 2021 07:34:21 -0700 (PDT) Received: from mail-1.ca.inter.net (mail-1.ca.inter.net [208.85.220.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8391B3A189E for ; Mon, 7 Jun 2021 07:34:21 -0700 (PDT) Received: from localhost (offload-3.ca.inter.net [208.85.220.70]) by mail-1.ca.inter.net (Postfix) with ESMTP id 5ED012EA3C6; Mon, 7 Jun 2021 10:34:20 -0400 (EDT) Received: from mail-1.ca.inter.net ([208.85.220.69]) by localhost (offload-3.ca.inter.net [208.85.220.70]) (amavisd-new, port 10024) with ESMTP id IjmdUAfTt9X0; Mon, 7 Jun 2021 10:11:26 -0400 (EDT) Received: from [192.168.168.101] (bras-base-toroon0246w-grc-16-70-53-126-140.dsl.bell.ca [70.53.126.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: outer@interlog.com) by mail-1.ca.inter.net (Postfix) with ESMTPSA id 6941A2EA06A; Mon, 7 Jun 2021 10:34:19 -0400 (EDT) From: Richard Outerbridge Message-Id: <105F02F8-E74E-436B-A637-58F1DDCDAF3B@interlog.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_02E055A9-784F-4163-B615-C73B56DCB655" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Mon, 7 Jun 2021 10:34:19 -0400 In-Reply-To: <773badc5fdc04c41a5ceea7ad4fe29fe@cert.org> Cc: "Salz, Rich" , Phillip Hallam-Baker , IETF SAAG , IRTF CFRG To: Roman Danyliw References: <773badc5fdc04c41a5ceea7ad4fe29fe@cert.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 14:34:27 -0000 --Apple-Mail=_02E055A9-784F-4163-B615-C73B56DCB655 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hmm =E2=80=A6 __outer > On 2021-06-07 (158), at 09:53:10, Roman Danyliw wrote: >=20 > Hi! > =20 > From: saag > On = Behalf Of Salz, Rich > Sent: Monday, June 7, 2021 9:45 AM > To: Phillip Hallam-Baker >; IETF SAAG >; IRTF CFRG > > Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is = a general problem > =20 > rfc7253 specifies OCB mode. But there is no OID specified to use OCB = with CMS, nor are there identifiers for use with JOSE. > =20 > For this particular case, a request to the IANA expert will get an = OID. (He=E2=80=99s a co-chair of LAMPS :) > =20 > I would like to propose that in future assignment of relevant OIDs and = JOSE identifiers be considered a requirement for similar work. If a spec = for a symmetric mode isn't sufficiently specified to enable = interoperable implementation in CMS and JOSE, it is not sufficiently = specified to be an RFC. > =20 > That=E2=80=99s a reasonable thing to ask for, and something that could = be caught by SECDIR or AD review.=20 [ =E2=80=A6 ] > [Roman] Agreed in the general case for the IETF stream. For RFC7253, = this review would have been during IESG conflict review because that = document was IRTF stream (which doesn=E2=80=99t have an SECDIR review, = AD review or even an IESG ballot). > =20 > Roman > =20 > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg = --Apple-Mail=_02E055A9-784F-4163-B615-C73B56DCB655 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hmm = =E2=80=A6
__outer

On = 2021-06-07 (158), at 09:53:10, Roman Danyliw <rdd@cert.org> = wrote:

Hi!
 
From: saag <saag-bounces@ietf.org> On Behalf = Of Salz, Rich
Sent: Monday, June 7, 2021 9:45 = AM
To: Phillip Hallam-Baker <phill@hallambaker.com>; = IETF SAAG <saag@ietf.org>; = IRTF CFRG <cfrg@irtf.org>Subject: Re: [saag] [CFRG] OCB does = not have an OID specified, that is a general problem
 
  • rfc7253 specifies OCB mode. But there is no OID = specified to use OCB with CMS, nor are there identifiers for use with = JOSE.
 
For this particular case, a request to = the IANA expert will get an OID.  (He=E2=80=99s a co-chair of LAMPS = :)
 
  • I would like to propose that in = future assignment of relevant OIDs and JOSE identifiers be considered a = requirement for similar work. If a spec for a symmetric mode isn't = sufficiently specified to enable interoperable implementation in CMS and = JOSE, it is not sufficiently specified to be an RFC.
 
That=E2=80=99s a reasonable thing to ask for, and something = that could be caught by SECDIR or AD review. 

[ =E2=80=A6 ]

[Roman] Agreed in the = general case for the IETF stream.  For RFC7253, this review would = have been during IESG conflict review because that document was IRTF = stream (which doesn=E2=80=99t have an SECDIR review, AD review or even = an IESG ballot).
 
Roman
 
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_02E055A9-784F-4163-B615-C73B56DCB655-- From nobody Mon Jun 7 08:01:05 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3313A198C for ; Mon, 7 Jun 2021 08:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Gv174ObM5Qk5 for ; Mon, 7 Jun 2021 08:00:58 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB03A3A198A for ; Mon, 7 Jun 2021 08:00:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 73C6F300BEA for ; Mon, 7 Jun 2021 11:00:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ilLpsVBAjyWw for ; Mon, 7 Jun 2021 11:00:51 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C43B8300BD6; Mon, 7 Jun 2021 11:00:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Mon, 7 Jun 2021 11:00:51 -0400 Cc: IETF SAAG , IRTF CFRG Content-Transfer-Encoding: quoted-printable Message-Id: <77C90766-F068-4710-8E03-D8A36FA026A4@vigilsec.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [saag] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 15:01:04 -0000 It would be very easy to write a document like RFC 5084 for AES-OCB. If = you want to do that, I'm sure that LAMPS could adopt and review it. Russ > On Jun 7, 2021, at 8:51 AM, Phillip Hallam-Baker = wrote: >=20 > Raising this in SAAG because this raises a policy issue and CFRG = because that is where the policy should be enforced. It is also relevant = to LAMPS but trying to avoid cross posting as everyone on the LAMPS list = is likely on SAAG. >=20 >=20 > rfc7253 specifies OCB mode. But there is no OID specified to use OCB = with CMS, nor are there identifiers for use with JOSE. >=20 > This is problematic to say the least. If an algorithm is worth = publishing as an RFC, there should be definitive identifiers for general = purpose packaging formats specified in that RFC. >=20 > I would like to propose that in future assignment of relevant OIDs and = JOSE identifiers be considered a requirement for similar work. If a spec = for a symmetric mode isn't sufficiently specified to enable = interoperable implementation in CMS and JOSE, it is not sufficiently = specified to be an RFC. >=20 > This would not cover TLS, IPSEC etc. since they have rather different = considerations. Algorithms are curated and selected as suites for TLS = for a start.=20 >=20 > I am not a fan of having multiple registries for specifying = identifiers for algorithms. In fact if I had my way, there would be a = single IANA text registry because while we could write a spec for a = cryptographic algorithm and call it SMTP, that would be silly.=20 >=20 > It seems to me that one registry for the ASN.1 identifiers and one for = text based identifiers is sufficient for all reasonable purposes. To the = extent that XML signature and encryption are still a thing, well why = don't we just specify a generic URN scheme for IANA registries and have = done. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Jun 7 17:58:33 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D523A19BA for ; Mon, 7 Jun 2021 17:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 gnrn5f-OwjVY for ; Mon, 7 Jun 2021 17:58:26 -0700 (PDT) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) (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 E2BC63A19BB for ; Mon, 7 Jun 2021 17:58:25 -0700 (PDT) Received: by mail-yb1-f176.google.com with SMTP id m9so21221378ybo.5 for ; Mon, 07 Jun 2021 17:58:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GOFyZ7YbXdKr6vWwJh1htyzNFjZ2/TgJbV8cc/pfujo=; b=i7l/wbCyXmY3G/FK3q5teetJZHHSBCF86SuYxvOTgE2mNqG//O/fKSN8+1OiuGDocX irnf8xi7jqKj8itBBcXx9dqWVb1HSIV6H6j1vwXJpHQIa07WT4hOzWUFmrVmZJTiLLsq igwXisRZpE+SnaKDhmzcAZxYuhTfAKf6tNbh/+FEY0mmLbdbEdHi8jFLRYWhfv29U9n6 vGwMvWAcOFXtZy/LybBJbeZQA4FY9ZtL8kCahG3AsBpmZpm1F0ToZYjdrWht0wTEx2+k 6ykN1dVus/42R0L4kOiy7a4D+Awt6yEx0LocuOxleN70cao2yu2oZgLT2jnaGk/1/5zn v/HA== X-Gm-Message-State: AOAM531tmb6DOZlHIi1ufrWFn0fYmRPRDA8WPBLfxbP/o7KjI1722NPc aQrcyaV6yLjN2j4Cis2G7fcoFWFxSYG8f8dDoGI= X-Google-Smtp-Source: ABdhPJxJyzwuJWSK/1zvlcYVpbtk96mINRWhw11reFuPOGiDbuKGa3PcV6CZGdUsbGI3VtKr45J/i2AgDdWRpdfWSlY= X-Received: by 2002:a05:6902:102a:: with SMTP id x10mr26147812ybt.213.1623113904559; Mon, 07 Jun 2021 17:58:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 7 Jun 2021 20:58:12 -0400 Message-ID: To: Neil Madden Cc: IETF SAAG , IRTF CFRG Content-Type: multipart/alternative; boundary="000000000000b61aed05c436a7be" Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 00:58:28 -0000 --000000000000b61aed05c436a7be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 7, 2021 at 10:02 AM Neil Madden wrote= : > Unless there is a compelling reason to do so, I=E2=80=99d prefer that reg= istering > algorithm identifiers for JOSE be a manual (and rare) step. JOSE provides > no way for consumers to advertise which Encryption Methods they support > (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so adding new optio= ns here can only > harm interoperability. > > (This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D = - as these can be > advertised in the JSON Web Key metadata). > I don't agree. JOSE has no algorithm negotiation mechanism because it is a format, not a protocol. After we went through the whole recommended/required algorithm thing on JOSE, it suddenly occurred to me that this was precisely none of JOSE's business. It is for the protocols and services built using XML Signature, JOSE, CMS etc. to decide what algorithms to require and/or recommend. JWK is a protocol built on top of JOSE, so it makes sense for that protocol to specify recommended algorithms. But the recommendations made in the JOSE spec have absolutely no bearing on the Mesh which uses parts of JOSE because being written six years later, the state of the art has moved on. The Mesh does not support RSA at all and the elliptic curve algs are X448 and Ed448. The curve 25519 versions are not supported for profile signing, etc. etc. I would expect the same to apply in the COSE world. Merely defining a code point for JOSE or CMS does not make a statement about the algorithm recommendation status. All it does is specify the one canonical identifier every application will use. It is not at all important what that identifier is (provided it is not an absurd length) it is critical that everyone use the same identifier though. --000000000000b61aed05c436a7be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <neil.e.madden@gmail.com> wrote:
Unless there is a compelling reason to do so, I=E2=80=99d prefer= that registering algorithm identifiers for JOSE be a manual (and rare) ste= p. JOSE provides no way for consumers to advertise which Encryption Methods= they support (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so addi= ng new options here can only harm interoperability.

(This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D - = as these can be advertised in the JSON Web Key metadata).
<= div>
I don&= #39;t agree. JOSE has no algorithm negotiation mechanism because it is a fo= rmat, not a protocol. After we went through the whole recommended/required = algorithm thing on JOSE, it suddenly occurred to me that this was precisely= none of JOSE's business. It is for the protocols and services built us= ing XML Signature, JOSE, CMS etc. to decide what algorithms to require and/= or recommend.=C2=A0

JWK i= s a protocol built on top of JOSE, so it makes sense for that protocol to s= pecify recommended algorithms. But the recommendations made in the JOSE spe= c have absolutely no bearing on the Mesh which uses parts of JOSE because b= eing written six years later, the state of the art has moved on. The Mesh d= oes not support RSA at all and the elliptic curve algs are X448 and Ed448. = The curve 25519 versions are not supported for profile signing, etc. etc.

I would expect the same to= apply in the COSE world. Merely defining=C2=A0a code point for JOSE or CMS= does not make a statement about the algorithm recommendation status. All i= t does is specify the one canonical identifier every application will use. = It is not at all important what that identifier is (provided it is not an a= bsurd length) it is critical that everyone use the same identifier though.<= /div>


--000000000000b61aed05c436a7be-- From nobody Tue Jun 8 00:53:37 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D763A26C8 for ; Tue, 8 Jun 2021 00:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vS6h9KjvSQMb for ; Tue, 8 Jun 2021 00:53:31 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 CF6043A26C1 for ; Tue, 8 Jun 2021 00:53:30 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id b145-20020a1c80970000b029019c8c824054so1250807wmd.5 for ; Tue, 08 Jun 2021 00:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=GIvTP9UQ7OGAYkJy1svCN2Sbs95NPLEARLnoAy2xQjw=; b=F2F0qYQWd72SlKLL5RxKc2nQ00U362sR9hT2v0m7kCqo9At1kHLz9QmpoKmnMUB6k7 meDXN+5GMakouTpivX2A0GG8pCEyRKZY7l2FLhyzbIxuVei9Mcjvhi//Ln2ql0PerPvf +6RkpNHayYonqDFidQ6OiaEINeBbjHjDt9qNAK+2NHpUWKCSFaxu0H5amCJMvne4cPZg aBR3zWhyp0KxDgZOMUy82YtJx8eU9UgUR4qQnGQoilGcnGby9fjMeyef8eja9eWc7+7m F5AB1jx1JXjJGCJQkVmxJdaNJrkqh8X22hQIZLJRL4QHP+5SJdZbR1dkZqT/UMxPwnlq Ixig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=GIvTP9UQ7OGAYkJy1svCN2Sbs95NPLEARLnoAy2xQjw=; b=JakVvdj2cWnQthIM75oZMdhmh/NePQPBTU9KMNL0yithnTLLNz9pfjHK5ePdrQaPYl Ul9jdq7pUgkBaXQnjgo1ZcLJZdtCPze66StL9tSBqOdJlGsaOWv19a04xU9ryNitKh2d CfrGTVoNU1aqBb0ONbT9OpbbLOlXE7yR1MVqPpkFUV1nWZeoI8QZhIkpHJoyeC16hEmD Wug/co4VB9e7VIz1bAFGe/v97t+/3SBiU7sJxr2L0M1ot1E9XUaiWdIN2j0s6teVGr7R gbJC3HUJK0db0beLNgnI+q8l634VU7CqoU2ObavnMCODVc4DZL3hEos79IWrre6WzbNF 7oKw== X-Gm-Message-State: AOAM530MbLNa13ZIzkcf9kBF3Gq0EFhDliFgDqihxD2cMkyjFKkNZ3BD CJOTaXeBXGvfJZo6VGHwPn2FAuoUS/ncgw== X-Google-Smtp-Source: ABdhPJyx/efAatZsiKh3rp/xswYi1XeAMWAk4Z3f2Hq8axB5yrbOyafJlb1qvPl+q0UUpLgV5vniMg== X-Received: by 2002:a7b:c417:: with SMTP id k23mr2703706wmi.71.1623138808242; Tue, 08 Jun 2021 00:53:28 -0700 (PDT) Received: from smtpclient.apple (113.87.75.194.dyn.plus.net. [194.75.87.113]) by smtp.gmail.com with ESMTPSA id n2sm20221011wmb.32.2021.06.08.00.53.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 00:53:27 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0032FC91-3F45-4DC5-A96F-AD9D192D3E07 Content-Transfer-Encoding: 7bit From: Neil Madden Mime-Version: 1.0 (1.0) Date: Tue, 8 Jun 2021 08:53:26 +0100 Message-Id: References: Cc: IETF SAAG , IRTF CFRG In-Reply-To: To: Phillip Hallam-Baker X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 07:53:36 -0000 --Apple-Mail-0032FC91-3F45-4DC5-A96F-AD9D192D3E07 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8 Jun 2021, at 01:58, Phillip Hallam-Baker wrote:= >=20 > =EF=BB=BF >> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden wro= te: >> Unless there is a compelling reason to do so, I=E2=80=99d prefer that reg= istering algorithm identifiers for JOSE be a manual (and rare) step. JOSE pr= ovides no way for consumers to advertise which Encryption Methods they suppo= rt (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so adding new optio= ns here can only harm interoperability. >>=20 >> (This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D -= as these can be advertised in the JSON Web Key metadata). >=20 > I don't agree. JOSE has no algorithm negotiation mechanism because it is a= format, not a protocol. After we went through the whole recommended/require= d algorithm thing on JOSE, it suddenly occurred to me that this was precisel= y none of JOSE's business. It is for the protocols and services built using X= ML Signature, JOSE, CMS etc. to decide what algorithms to require and/or rec= ommend.=20 Doesn=E2=80=99t this contradict your desire to have a single IANA algorithm r= egistry? If individual application protocols are to state which algorithms t= o use then they need a registry each to state this.=20 >=20 > JWK is a protocol built on top of JOSE, so it makes sense for that protoco= l to specify recommended algorithms. This is rather backwards: JWK is part of JOSE and indeed JOSE depends on JWK= (see for example the =E2=80=9Cjwk=E2=80=9D and =E2=80=9Cepk=E2=80=9D header= s).=20 > But the recommendations made in the JOSE spec have absolutely no bearing o= n the Mesh which uses parts of JOSE because being written six years later, t= he state of the art has moved on. The Mesh does not support RSA at all and t= he elliptic curve algs are X448 and Ed448. The curve 25519 versions are not s= upported for profile signing, etc. etc. >=20 > I would expect the same to apply in the COSE world. Merely defining a code= point for JOSE or CMS does not make a statement about the algorithm recomme= ndation status. Well it does actually - see the =E2=80=9CJOSE Implementation Requirements=E2= =80=9D field: https://www.iana.org/assignments/jose/jose.xhtml#web-signature= -encryption-algorithms And the reason for this is because the algorithms are implemented by JOSE li= braries. Indeed, this is the whole point of JOSE, that applications don=E2=80= =99t need to implement their own algorithms but can just use a preexisting l= ibrary.=20 > All it does is specify the one canonical identifier every application will= use. It is not at all important what that identifier is (provided it is not= an absurd length) it is critical that everyone use the same identifier thou= gh. If different applications are going to specify different algorithms then thi= s somewhat argues against your point: they _don=E2=80=99t_ need to use the s= ame algorithm identifiers as other applications in that case.=20 But I think we=E2=80=99re rather getting off the track here because as I men= tioned in my first email, OCB would be standardised as an Encryption Method (= =E2=80=9Cenc=E2=80=9D header value). This introduces more complications. JOS= E supports encrypting a message to multiple recipients, each of which can us= e a different key management algorithm (=E2=80=9Calg=E2=80=9D). But the cont= ent of the message has to be encrypted using a common symmetric Encryption M= ethod that all the recipients understand. This is why introducing new Encryp= tion Methods is problematic because as the number of options goes up, the ch= ances of finding an algorithm that all recipients agree on reduces. =20 (The alternative is that we register as many new =E2=80=9Cenc=E2=80=9D value= s as we like but they are all effectively ignored because everyone uses =E2=80= =9CA128CBC-HS256=E2=80=9D as the only thing guaranteed to work everywhere. T= his is not the case currently because there are only a few =E2=80=9Cenc=E2=80= =9D options and so most libraries implement all of them).=20 In 2021, I think OCB has very few advantages over JOSE=E2=80=99s existing GC= M Encryption Methods, so I think it is much more trouble than it=E2=80=99s w= orth to specify it for use there. If we=E2=80=99re going to expand the =E2=80= =9Cenc=E2=80=9D registry I=E2=80=99d rather it was for an algorithm with sig= nificant advantages over the existing alternatives, such as misuse resistanc= e or better performance on low-end hardware.=20 =E2=80=94 Neil= --Apple-Mail-0032FC91-3F45-4DC5-A96F-AD9D192D3E07 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 8 Jun 2021, at 01:58, P= hillip Hallam-Baker <phill@hallambaker.com> wrote:

=EF=BB=BF
On Mon, Jun 7, 2021 at 10:02 AM Nei= l Madden <neil.e.madden@gmail.= com> wrote:
Unless there is a compelling reason to do s= o, I=E2=80=99d prefer that registering algorithm identifiers for JOSE be a m= anual (and rare) step. JOSE provides no way for consumers to advertise which= Encryption Methods they support (=E2=80=9Cenc=E2=80=9D - which is what OCB w= ould be), so adding new options here can only harm interoperability.

(This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D - a= s these can be advertised in the JSON Web Key metadata).

I don't a= gree. JOSE has no algorithm negotiation mechanism because it is a format, no= t a protocol. After we went through the whole recommended/required algorithm= thing on JOSE, it suddenly occurred to me that this was precisely none of J= OSE's business. It is for the protocols and services built using XML Signatu= re, JOSE, CMS etc. to decide what algorithms to require and/or recommend.&nb= sp;

Doesn=E2=80=99t t= his contradict your desire to have a single IANA algorithm registry? If indi= vidual application protocols are to state which algorithms to use then they n= eed a registry each to state this. 

=

JWK is a protocol built on top of JOSE, so it m= akes sense for that protocol to specify recommended algorithms.
<= /div>

This is rather backwards: JWK is= part of JOSE and indeed JOSE depends on JWK (see for example the =E2=80=9Cj= wk=E2=80=9D and =E2=80=9Cepk=E2=80=9D headers). 

But the recommendation= s made in the JOSE spec have absolutely no bearing on the Mesh which uses pa= rts of JOSE because being written six years later, the state of the art has m= oved on. The Mesh does not support RSA at all and the elliptic curve algs ar= e X448 and Ed448. The curve 25519 versions are not supported for profile sig= ning, etc. etc.
=
I would exp= ect the same to apply in the COSE world. Merely defining a code point f= or JOSE or CMS does not make a statement about the algorithm recommendation s= tatus.

Well it does= actually - see the =E2=80=9CJOSE Implementation Requirements=E2=80=9D field= : https://www.iana.org/assignments/jose/jose.xhtml= #web-signature-encryption-algorithms

And the re= ason for this is because the algorithms are implemented by JOSE libraries. I= ndeed, this is the whole point of JOSE, that applications don=E2=80=99t need= to implement their own algorithms but can just use a preexisting library.&n= bsp;

All it does is specify the one canonical identifier every application wi= ll use. It is not at all important what that identifier is (provided it is n= ot an absurd length) it is critical that everyone use the same identifier th= ough.

If different applications are going to specify d= ifferent algorithms then this somewhat argues against your point: they _don=E2= =80=99t_ need to use the same algorithm identifiers as other applications in= that case. 

But I think we=E2=80=99re rather g= etting off the track here because as I mentioned in my first email, OCB woul= d be standardised as an Encryption Method (=E2=80=9Cenc=E2=80=9D header valu= e). This introduces more complications. JOSE supports encrypting a message t= o multiple recipients, each of which can use a different key management algo= rithm (=E2=80=9Calg=E2=80=9D). But the content of the message has to be encr= ypted using a common symmetric Encryption Method that all the recipients und= erstand. This is why introducing new Encryption Methods is problematic becau= se as the number of options goes up, the chances of finding an algorithm tha= t all recipients agree on reduces.  

(The alte= rnative is that we register as many new =E2=80=9Cenc=E2=80=9D values as we l= ike but they are all effectively ignored because everyone uses =E2=80=9CA128= CBC-HS256=E2=80=9D as the only thing guaranteed to work everywhere. This is n= ot the case currently because there are only a few =E2=80=9Cenc=E2=80=9D opt= ions and so most libraries implement all of them). 

In 2021, I think OCB has very few advantages over JOSE=E2=80=99s exist= ing GCM Encryption Methods, so I think it is much more trouble than it=E2=80= =99s worth to specify it for use there. If we=E2=80=99re going to expand the= =E2=80=9Cenc=E2=80=9D registry I=E2=80=99d rather it was for an algorithm w= ith significant advantages over the existing alternatives, such as misuse re= sistance or better performance on low-end hardware. 

=E2=80=94 Neil
= --Apple-Mail-0032FC91-3F45-4DC5-A96F-AD9D192D3E07-- From nobody Tue Jun 8 09:36:36 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D593A35FD for ; Tue, 8 Jun 2021 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 xSte8GaG5pRT for ; Tue, 8 Jun 2021 09:36:25 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) (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 304B73A35FE for ; Tue, 8 Jun 2021 09:36:25 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id g142so11737387ybf.9 for ; Tue, 08 Jun 2021 09:36:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FuLoDp5ukjk8n4Ca21mzHrfBZCXw+IEGij4HV30d3RM=; b=uVjhJUWJFyUQfdsLn8imkXOeYAmWfhbxPCBYBPZ4xlNI18Ebw+Hm7fwv2j49EDPntv ndfQrmRybHKMZdFxoWyo0nlZLgOAx//mzrI6SXom7Y6kNDjeJIp8U1AHyxBM4TGjC+Jv IDXj9Dae3pJUDVVzq7Bwjbe+QdqMyA2r6tWQXS/8znhAyQh30Qbzabr8A5KS7dZxjvhx jIG7O1ro+powIthKdJcA+9n1E7pH4CoVgC9fOdIXyi/zzqWhiZKtr/u4fkMAB3KVkm3J Um8QCDKhJioM6i5PslMYXELiYNfKogw79yco91hIxsclY5eIZVWjtTh6RxubVlhF+dJT ZnLA== X-Gm-Message-State: AOAM532UFOC8ICJHPmD6cxKn+8/j7lcOssOXsR6dmMfdCpwRk8WRtnWi R4bRVKCsfb6dnM1qPfYEK7VoKkvvXCOsTEVzREw= X-Google-Smtp-Source: ABdhPJzeJdHU9Xig3i7OQbqAq/IZtorRdj6w52xe1sJ0jId7kvsxvjfbxEn+w/ZBu+EFBhig6Y3Iz2kxHPqSv03kKqg= X-Received: by 2002:a25:6005:: with SMTP id u5mr32144477ybb.56.1623170184117; Tue, 08 Jun 2021 09:36:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 8 Jun 2021 12:36:14 -0400 Message-ID: To: Neil Madden Cc: IETF SAAG , IRTF CFRG Content-Type: multipart/alternative; boundary="0000000000003c059505c443c2b5" Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 16:36:30 -0000 --0000000000003c059505c443c2b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My view of the way IETF/IRTF should consider cryptographic algorithms might be described as a 'fat waist model' First of all we have general discussion of the canon of prefered cryptographic algorithms for use in IETF protocols in SAAG and CFRG. There is a lot of overlap between the groups of course but CFRG is the primary gatekeeper that algorithms must pass to be added to the canon and SAAG is the primary grim reaper taking them away. Once we decide an algorithm is no longer fit for purpose, we want to remove it from the recommendations for every current standard. Merely adding an algorithm to the canon does not mean that every current standard must allow it. All that it means is that it is available for those standards which might use it. This canon represents the base of the pyramid. At the very top of the pyramid we have protocol standards. Here we typically look to limit the choices both for interoperability and for security. The algorithm choices are taken from the canon but they are in most cases going to be a subset of the canon. As a general rule we would normally want to limit ourselves to one primary and one backup for each cryptographic function. This is because the security of the system is generally the security of the weakest algorithm, Adding stronger algorithms to a protocol suite does not make the protocol any stronger, only removing the obsolete weaker algorithms does that. Since removing algorithms is typically a costly and painful process, most new protocol proposals should adopt the strongest algorithm choices that are appropriate at the time it is introduced. The choices I would have made in 2014 have no bearing on the choices I would make in 2021. One of the simplifications I have made in the Mesh is to require 448 bit ECDH, 256 bit AES and 512 bit SHA-2 or SHA-3. Those are entirely defensible choices in 2021, I don't think I could have gotten away with those in 2014 and people would have been looking at me funny if I proposed them in 2005. And then in the middle of the pyramid we have standards which aren't actually protocols in their own right but are components used in protocols. In the security area these are our cryptographic format specs such as PKCS#7/CMS, XML Signature, XML Encryption, JOSE, DARE, etc. etc. I was one of the people who spent many hours debating the inclusion or exclusion of various algorithms from most of those formats and it is only now that I have realized that the entire discussion was a waste of time because cryptographic format specs do not raise interoperability issues, protocols do. Since these are not protocols in their own right, the interoperability issues are very different to those of a protocol. They might apply to someone who is going to write a standalone library for a format. But even that seems like the wrong approach to me. My reference code for the Mesh contains a JOSE and a DARE library. Neither of which actually contains any algorithm code. The algorithms are implemented in .NET Core which in turn uses OpenSSL or Windows crypto or in the case of algorithms .NET does not support, in my own code. [My implementation has 2197 lines of executable code that provide packaging of cryptographic algorithms so they can be applied in a consistent manner and only 1439 lines that implement algorithms] Does the fact that JOSE supports RSA require the Mesh to support RSA? - No. Does the fact that JOSE requires HMAC-SHA2 256 bit require the Mesh to use it? - No. Does the fact that JOSE does not define an identifier for AES-OCB prevent the Mesh using it? - No. Should the Mesh define its own set of algorithm identifiers to compete with those used by JOSE? - Oh please no. Of course, the Mesh is really built on DARE which is based on JOSE but has quite a bit added and even more taken away. The Mesh approach to crypto is that there should be exactly one way to do a given thing. So where JOSE has to allow six different key wrapping approaches, the Mesh has one, where JOSE supports three cipher suite strengths, the Mesh has one, etc. etc. It is this cryptographic format that I consider the 'fat waist'. Basically any cryptographic algorithm that is a part of the canon can be specified here and in some cases we are going to have algorithms that are not specified. We can write text that says that an S/MIME application MUST NOT sign using MD5 or encrypt using DES but both have to be in any real world application and that can never change because Alice has to be able to read the message Bob sent in 1995 in 2021 and possibly in 2050. The one area in which cryptographic formats do raise interop issues is when they are used as a file format. And only some formats are used as file formats. rfc7518 (ietf.org) Registering the algorithms and identifiers here, rather than in the JWS, JWE, and JWK specifications, is intended to allow them to remain unchanged in the face of changes in the set of Required, Recommended, Optional, and Deprecated algorithms over time. This also allows changes to the JWS, JWE, and JWK specifications without changing this document. On Tue, Jun 8, 2021 at 3:53 AM Neil Madden wrote: > On 8 Jun 2021, at 01:58, Phillip Hallam-Baker > wrote: > > > =EF=BB=BF > On Mon, Jun 7, 2021 at 10:02 AM Neil Madden > wrote: > >> Unless there is a compelling reason to do so, I=E2=80=99d prefer that re= gistering >> algorithm identifiers for JOSE be a manual (and rare) step. JOSE provide= s >> no way for consumers to advertise which Encryption Methods they support >> (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so adding new opti= ons here can only >> harm interoperability. >> >> (This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D= - as these can >> be advertised in the JSON Web Key metadata). >> > > I don't agree. JOSE has no algorithm negotiation mechanism because it is = a > format, not a protocol. After we went through the whole > recommended/required algorithm thing on JOSE, it suddenly occurred to me > that this was precisely none of JOSE's business. It is for the protocols > and services built using XML Signature, JOSE, CMS etc. to decide what > algorithms to require and/or recommend. > > > Doesn=E2=80=99t this contradict your desire to have a single IANA algorit= hm > registry? If individual application protocols are to state which algorith= ms > to use then they need a registry each to state this. > Not at all. My point is that the purpose of a registry is limited to assigning a signifier to one or more signified. It is not for IANA to specify that RSA is required or not, that is a WG decision. > JWK is a protocol built on top of JOSE, so it makes sense for that > protocol to specify recommended algorithms. > > > This is rather backwards: JWK is part of JOSE and indeed JOSE depends on > JWK (see for example the =E2=80=9Cjwk=E2=80=9D and =E2=80=9Cepk=E2=80=9D = headers). > Well yes and no, JWK also pops up in other contexts. OAUTH2 would have been a better example. JOSE doesn't even specify the serialization format, it is a component of a protocol, not a protocol. > But the recommendations made in the JOSE spec have absolutely no bearing > on the Mesh which uses parts of JOSE because being written six years late= r, > the state of the art has moved on. The Mesh does not support RSA at all a= nd > the elliptic curve algs are X448 and Ed448. The curve 25519 versions are > not supported for profile signing, etc. etc. > > I would expect the same to apply in the COSE world. Merely defining a cod= e > point for JOSE or CMS does not make a statement about the algorithm > recommendation status. > > > Well it does actually - see the =E2=80=9CJOSE Implementation Requirements= =E2=80=9D field: > https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption= -algorithms > > And the reason for this is because the algorithms are implemented by JOSE > libraries. Indeed, this is the whole point of JOSE, that applications don= =E2=80=99t > need to implement their own algorithms but can just use a preexisting > library. > And merely assigning a code point does not change the recommendations for implementing algorithms in a 'JOSE Library'. Since I wrote my own JOSE library in less than a week, I have a hard time believing that it is the JOSE part that is critical. And since I used the .NET crypto as base, the recommendations in the JOSE specs were not remotely relevant. All it does is specify the one canonical identifier every application will > use. It is not at all important what that identifier is (provided it is n= ot > an absurd length) it is critical that everyone use the same identifier > though. > > > If different applications are going to specify different algorithms then > this somewhat argues against your point: they _don=E2=80=99t_ need to use= the same > algorithm identifiers as other applications in that case. > There is no reason why the algorithm suite for the Mesh should be the same as that for SIP and plenty of reasons why it needs to be different. The Mesh uses threshold cryptography which only works with DH and ECDH algorithms for a start. Even if RSA was still viable from a security point of view, I couldn't use it. OCB was patent encumbered when JOSE was written, it is not today. The advantages of OCB over GSM are significant but not something that is worth losing backwards compatibility over. > But I think we=E2=80=99re rather getting off the track here because as I = mentioned > in my first email, OCB would be standardised as an Encryption Method (=E2= =80=9Cenc=E2=80=9D > header value). This introduces more complications. JOSE supports encrypti= ng > a message to multiple recipients, each of which can use a different key > management algorithm (=E2=80=9Calg=E2=80=9D). But the content of the mess= age has to be > encrypted using a common symmetric Encryption Method that all the > recipients understand. This is why introducing new Encryption Methods is > problematic because as the number of options goes up, the chances of > finding an algorithm that all recipients agree on reduces. > Since I have 0 users and 1 implementation, my scope for deciding algorithm choices is radically different from that of others. You keep conflating the concerns that apply to existing JOSE applications to the concerns that properly apply to JOSE. > (The alternative is that we register as many new =E2=80=9Cenc=E2=80=9D va= lues as we like > but they are all effectively ignored because everyone uses =E2=80=9CA128C= BC-HS256=E2=80=9D > as the only thing guaranteed to work everywhere. This is not the case > currently because there are only a few =E2=80=9Cenc=E2=80=9D options and = so most libraries > implement all of them). > OATH2 allows use of 128 bit AES and 256 bit SHA-2. The Mesh requires 256 bit AES and 512 bit SHA-2 or SHA-3. And that is exactly what you would expect. OAUTH2 is an attempt to define an authorization scheme that is conflated into an authentication mechanism that manages to squeeze itself into the legacy deployed base of Web Browsers. The Mesh is a Threshold PKI whose primary function is management of private keys. My problems have absolutely nothing in common with those of OAUTH2 which is why their algorithm choices have no bearing on mine any more than TLS is beholden to CMS or CMS to OpenPGP. > In 2021, I think OCB has very few advantages over JOSE=E2=80=99s existing= GCM > Encryption Methods, so I think it is much more trouble than it=E2=80=99s = worth to > specify it for use there. If we=E2=80=99re going to expand the =E2=80=9Ce= nc=E2=80=9D registry I=E2=80=99d > rather it was for an algorithm with significant advantages over the > existing alternatives, such as misuse resistance or better performance on > low-end hardware. > This was discussed at some length on the cryptography list and the overwhelming feeling there was to go for OCB. That was not a decision taken lightly as it required me to write the implementation. GCM is a stream cipher and the uses in the Mesh clearly require a block cipher which means CBC and OCB are the only acceptable choices. --0000000000003c059505c443c2b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My view of the way IETF/IRTF should consider cryptographic= algorithms might be described as a 'fat waist model'

First of all we have general discussio= n of the canon of prefered cryptographic algorithms for use in IETF protoco= ls in SAAG and CFRG. There is a lot of overlap between the groups of course= but CFRG is the primary gatekeeper that algorithms must pass to be added t= o the canon and SAAG is the primary grim reaper taking them away.

Once we decide an algorithm is no longer fit for= purpose, we want to remove it from the recommendations for every current s= tandard. Merely adding an algorithm to the canon does not mean that every c= urrent standard must allow it. All that it means is that it is available fo= r those standards which might use it.

This canon represents the base of the pyramid.


At the very top of the pyramid we have protoco= l standards. Here we typically=C2=A0look to limit the choices both for inte= roperability and for security. The algorithm choices are taken from the can= on but they are in most cases going to be a subset of the canon. As a gener= al rule we would normally want to limit ourselves to one primary and one ba= ckup for each cryptographic function. This is because the security of the s= ystem is generally the security of the weakest algorithm, Adding stronger a= lgorithms to a protocol suite does not make the protocol any stronger, only= removing the obsolete weaker algorithms does that.

Since removing algorithms is typically a costly = and painful=C2=A0process, most new protocol proposals should adopt the stro= ngest algorithm choices that are appropriate at the time it is introduced. = The choices I would have made in 2014 have no bearing on the choices I woul= d make in 2021. One of the simplifications I have made in the Mesh is to re= quire 448 bit ECDH, 256 bit AES and 512 bit SHA-2 or SHA-3. Those are entir= ely defensible choices in 2021, I don't think I could have gotten away = with those in 2014 and people would have been looking at me funny if I prop= osed them in 2005.=C2=A0

=
And then i= n the middle of the pyramid we have standards which aren't actually pro= tocols in their own right but are components used in protocols. In the secu= rity area these are our cryptographic format specs such as PKCS#7/CMS, XML = Signature, XML Encryption, JOSE, DARE, etc. etc.

I was one of the people who spent many hours debati= ng the inclusion or exclusion of various algorithms from most of those form= ats and it is only now that I have realized that the entire discussion was = a waste=C2=A0of time because=C2=A0cryptographic format specs do not raise i= nteroperability issues, protocols do.

Since these are not protocols in their own right, the inte= roperability issues are very different to those of a protocol. They might a= pply to someone who is going to write a standalone library for a format. Bu= t even that seems like the wrong approach to me. My reference code for the = Mesh contains a JOSE and a DARE library. Neither of which actually contains= any algorithm code. The algorithms are implemented in .NET Core which in t= urn uses OpenSSL or Windows crypto or in the case of algorithms .NET does n= ot support, in my own code.=C2=A0

[My implementation has 2197 lines of executable code that provid= e packaging of cryptographic algorithms so they can be applied in a consist= ent manner and only 1439 lines that implement algorithms]

Does the fact that JOSE supports RSA r= equire the Mesh to support RSA? - No.
Does the fact that JOSE requires HMAC-SHA2 256 bit r= equire the Mesh to use it? - No.
Does the fact that JOSE does not define an identifier for= AES-OCB prevent the Mesh using it? - No.
Should the Mesh define its own set of algori= thm identifiers to compete with those used by JOSE? - Oh please no.

Of course, the Mesh is really built on DARE = which is based on JOSE but has quite a bit added and even more taken away. = The Mesh approach to crypto is that there should be exactly one way to do a= given thing. So where JOSE has to allow six different key wrapping approac= hes, the Mesh has one, where JOSE supports three cipher suite strengths, th= e Mesh has one, etc. etc.=C2=A0

It is this=C2=A0cryptographic format that I consider the 'fat wa= ist'. Basically any cryptographic algorithm that is a part of the canon= can be specified=C2=A0here and in some cases we are going to have algorith= ms that are not specified. We can write text that says that an S/MIME appli= cation MUST NOT sign using MD5 or encrypt using DES but both have to be in = any real world application and that can never change because Alice has to b= e able to read the message Bob sent in 1995 in 2021 and possibly in 2050.= =C2=A0

The one area in wh= ich cryptographic formats do raise interop issues is when they are used as = a file format. And only some formats are used as file formats.=C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">

rfc7518 (ietf.org)

  =
 Registering the algorithms and identifiers here, rather than in the
   JWS, JWE, and JWK specifications, is intended to allow them to remain
   unchanged in the face of changes in the set of Required, Recommended,
   Optional, and Deprecated algorithms over time.  This also allows
   changes to the JWS, JWE, and JWK specifications without changing this
   document.

On Tue, Jun 8, 2021 at 3:53 AM Neil Madden <neil.e.madden@gmail.com> wrot= e:
On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:

=EF=BB=BF
On Mon, Jun 7, 202= 1 at 10:02 AM Neil Madden <neil.e.madden@gmail.com> wrote:
Unl= ess there is a compelling reason to do so, I=E2=80=99d prefer that register= ing algorithm identifiers for JOSE be a manual (and rare) step. JOSE provid= es no way for consumers to advertise which Encryption Methods they support = (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so adding new options= here can only harm interoperability.

(This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D - = as these can be advertised in the JSON Web Key metadata).
<= div>
I don't agree. JOSE has no= algorithm negotiation mechanism because it is a format, not a protocol. Af= ter we went through the whole recommended/required algorithm thing on JOSE,= it suddenly occurred to me that this was precisely none of JOSE's busi= ness. It is for the protocols and services built using XML Signature, JOSE,= CMS etc. to decide what algorithms to require and/or recommend.=C2=A0

Doesn=E2=80=99t this co= ntradict your desire to have a single IANA algorithm registry? If individua= l application protocols are to state which algorithms to use then they need= a registry each to state this.=C2=A0

Not at all. My point is t= hat the purpose of a registry is limited to assigning a signifier to one or= more signified. It is not for IANA to specify that RSA is required or not,= that is a WG decision.
=C2=A0
JWK is a protocol= built on top of JOSE, so it makes sense for that protocol to specify recom= mended algorithms.

= This is rather backwards: JWK is part of JOSE and indeed JOSE depends on JW= K (see for example the =E2=80=9Cjwk=E2=80=9D and =E2=80=9Cepk=E2=80=9D head= ers).=C2=A0

Well yes and no, JWK also pops up in ot= her contexts. OAUTH2 would have been a better example.=C2=A0

JOSE doesn'= ;t even specify the serialization format, it is a component of a protocol, = not a protocol.
=C2=A0
But the recommendations made in the JOSE spec have absolutely no bear= ing on the Mesh which uses parts of JOSE because being written six years la= ter, the state of the art has moved on. The Mesh does not support RSA at al= l and the elliptic curve algs are X448 and Ed448. The curve 25519 versions = are not supported for profile signing, etc. etc.

I would expect the same = to apply in the COSE world. Merely defining=C2=A0a code point for JOSE or C= MS does not make a statement about the algorithm recommendation status.

Well it does actually= - see the =E2=80=9CJOSE Implementation Requirements=E2=80=9D field:=C2=A0<= a href=3D"https://www.iana.org/assignments/jose/jose.xhtml#web-signature-en= cryption-algorithms" target=3D"_blank">https://www.iana.org/assignments/jos= e/jose.xhtml#web-signature-encryption-algorithms

And the reason for this is because the algorithms are implemented by JOS= E libraries. Indeed, this is the whole point of JOSE, that applications don= =E2=80=99t need to implement their own algorithms but can just use a preexi= sting library.=C2=A0

And merely assigning a code po= int does not change the recommendations for implementing algorithms in a &#= 39;JOSE Library'.

Sin= ce I wrote my own JOSE library in less than a week, I have a hard time beli= eving that it is the JOSE part that is critical. And since I used the .NET = crypto as base, the recommendations in the JOSE specs were not remotely rel= evant.


Al= l it does is specify the one canonical identifier every application will us= e. It is not at all important what that identifier is (provided it is not a= n absurd length) it is critical that everyone use the same identifier thoug= h.

If different applications are going to specify = different algorithms then this somewhat argues against your point: they _do= n=E2=80=99t_ need to use the same algorithm identifiers as other applicatio= ns in that case.=C2=A0

There is no reason why the a= lgorithm suite for the Mesh should be the same as that for SIP and plenty o= f reasons why it needs to be different. The Mesh uses threshold cryptograph= y which only works with DH and ECDH algorithms for a start. Even if RSA was= still viable from a security point of view, I couldn't use it. OCB was= patent encumbered when JOSE was written, it is not today. The advantages o= f OCB over GSM are=C2=A0significant but not something that is worth losing = backwards compatibility over.

=C2=A0
But I thin= k we=E2=80=99re rather getting off the track here because as I mentioned in= my first email, OCB would be standardised as an Encryption Method (=E2=80= =9Cenc=E2=80=9D header value). This introduces more complications. JOSE sup= ports encrypting a message to multiple recipients, each of which can use a = different key management algorithm (=E2=80=9Calg=E2=80=9D). But the content= of the message has to be encrypted using a common symmetric Encryption Met= hod that all the recipients understand. This is why introducing new Encrypt= ion Methods is problematic because as the number of options goes up, the ch= ances of finding an algorithm that all recipients agree on reduces.=C2=A0= =C2=A0

Since I have 0 users and 1 implementation, m= y scope for deciding algorithm choices is radically different from that of = others.

You keep conflati= ng the concerns that apply to existing JOSE applications to the concerns th= at properly apply to JOSE.

=C2=A0
(The alternative i= s that we register as many new =E2=80=9Cenc=E2=80=9D values as we like but = they are all effectively ignored because everyone uses =E2=80=9CA128CBC-HS2= 56=E2=80=9D as the only thing guaranteed to work everywhere. This is not th= e case currently because there are only a few =E2=80=9Cenc=E2=80=9D options= and so most libraries implement all of them).=C2=A0

OATH2 allows use of 128 bit AES and 256 bit SHA-2. The Mesh requires 256 = bit AES and 512 bit SHA-2 or SHA-3. And that is exactly what=C2=A0you would= expect. OAUTH2 is an attempt to define an authorization scheme that is con= flated into an authentication=C2=A0mechanism that manages to squeeze=C2=A0i= tself into the legacy deployed base of Web Browsers. The Mesh is a Threshol= d PKI whose primary function is management of private keys. My problems hav= e absolutely nothing in common with those of OAUTH2 which is why their algo= rithm choices have no bearing on mine any more than TLS is beholden to CMS = or CMS to OpenPGP.
=C2=A0
In 2021, I think OCB has very few advantages over J= OSE=E2=80=99s existing GCM Encryption Methods, so I think it is much more t= rouble than it=E2=80=99s worth to specify it for use there. If we=E2=80=99r= e going to expand the =E2=80=9Cenc=E2=80=9D registry I=E2=80=99d rather it = was for an algorithm with significant advantages over the existing alternat= ives, such as misuse resistance or better performance on low-end hardware.= =C2=A0

This was discussed at some length on the cry= ptography list and the overwhelming feeling there was to go for OCB. That w= as not a decision taken lightly as it required me to write the implementati= on. GCM is a stream cipher and the uses in the Mesh clearly require a block= cipher which means CBC and OCB are the only acceptable choices.

=
=C2=A0
--0000000000003c059505c443c2b5-- From nobody Wed Jun 9 08:04:00 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775EE3A1AF7 for ; Wed, 9 Jun 2021 08:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 RhokLQxSqxvb for ; Wed, 9 Jun 2021 08:03:52 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 C8AC73A1AF4 for ; Wed, 9 Jun 2021 08:03:51 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id r20so2913895qtp.3 for ; Wed, 09 Jun 2021 08:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i2qcqbQFTuXrLRW3O5VgX6EYFiIQzj0PQSoZCdBAabI=; b=VSQEihonu+V18KGmleuFuHHDjjev65A0GFGLcFsOAuYGqwt7dtebI3+9WZGXCRHITB ded9I5yuiWEXDbTobop+PIc8L7JmNa9+KdYS23jAmNJcTPifKnX2CApxmcrQ79W28WqK IpL+yfFG8naxn9IK6TgLYhZQoee6uZxDorRdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i2qcqbQFTuXrLRW3O5VgX6EYFiIQzj0PQSoZCdBAabI=; b=oHy7F5MmSJ1IKOciX0OpSwYiiXHYgitMwNQl6fCmW7RouKFPH1JcGYD8ih2oI8Piuh 4vod7Jrm8IauHliYa5gC3GymGbBwT189iGX8byFlUAiSiKBBlDQxAbIcnanevtZ9Si7S QbboTCl5CozIgfIyl1TAYGmQdP/Y6cQq72L/wYp6xQXUGY6OnoaU6kg/nP7+9FcI3ndq hDUCnyxGBIXJsaoipUb08yR4P9kbdFc2kTsLkwW4Fn259MgeIVSiYMHe/KB+JSGHvf9/ npWbaFfVOxkNkEeh9cQBC9sbcoQ2jmlRq+mBeijgyUy0YCPcopo7eLhH7KHJTgVahz1I psvw== X-Gm-Message-State: AOAM531DdFpkgpE7Bxn+DSAgBPA/EjaOH0RDRWFXsnUTIvvp+I4tfG0J 8t1rS5DzR8LlTmGtjcQtTxiA5g== X-Google-Smtp-Source: ABdhPJx5xQELwC16xYQ6OtQaiz6HpvHrbqRc43VJlOhRgX/y3KVt90/TdYcbnqA5zUFKRXX4Hvi0VQ== X-Received: by 2002:a05:622a:15:: with SMTP id x21mr358542qtw.236.1623251028526; Wed, 09 Jun 2021 08:03:48 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id m19sm142479qtp.93.2021.06.09.08.03.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 08:03:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Sean Turner In-Reply-To: <12861641c9f345868f3201bfac6c3db9@cert.org> Date: Wed, 9 Jun 2021 11:03:46 -0400 Cc: "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> References: <12861641c9f345868f3201bfac6c3db9@cert.org> To: Roman Danyliw X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 15:03:57 -0000 Roman, I have but one point to raise and then some cosmetic nits (cosmetic = because compilers ignore whitespace). 0) Point to Raise: re: AllWantBacks. I am not entirely sure whether what is there for = swb-ers-all WANT-BACK merely defines the new value or whether it also = adds it to the list of available AllWantBacks. AllWantBacks is imported = from RFC 5912: AllWantBacks WANT-BACK ::=3D { WantBackSet | ACertWantBackSet | AnyWantBackSet, ... } To add swb-ers-all to the list, I wonder whether merely defining it is = enough. Is there something more that needs to be done to get it into the = list as the fourth option? 1) Cosmetic Nits: Header: s/New ASN.1 Modules for the Evidence Recor /New ASN.1 Modules for the Evidence Record s2 (remove space, add space): s/{ v1(1) } ,/{ v1(1) }, s/AttributeSet{{ERSAttrSet}}/AttributeSet {{ERSAttrSet}} s3: Since the ExpandedWantBacks are All, New, and ERS might consider = reorganizing them in the ASN to match that pattern. s (fix indention of evidence record)/ EvidenceRecordWantBack ::=3D SEQUENCE { targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), evidenceRecord EvidenceRecord OPTIONAL } / EvidenceRecordWantBack ::=3D SEQUENCE { targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), evidenceRecord EvidenceRecord OPTIONAL } s/{id-swb 16 }/{ id-swb 16 } s/{id-swb 17 }/{ id-swb 17 } s/{id-swb 18 }/{ id-swb 18 } s/{id-swb 19 }/{ id-swb 19 } s/{id-swb 20 }/{ id-swb 20 } > On May 14, 2021, at 16:45, Roman Danyliw wrote: >=20 > Hi! >=20 > Per the community interest and dispatch result at IETF 110 [1], I am = AD sponsoring draft-housley-ers-asn1-modules [2]. >=20 > I welcome early feedback or reviews on this document. >=20 > Regards, > Roman >=20 > [1] https://datatracker.ietf.org/doc/minutes-110-secdispatch/ > [2] https://datatracker.ietf.org/doc/draft-housley-ers-asn1-modules/ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Jun 10 10:31:29 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406773A0E1C for ; Thu, 10 Jun 2021 10:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 hs2bVkeRbMWk for ; Thu, 10 Jun 2021 10:31:22 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 56E853A0E1A for ; Thu, 10 Jun 2021 10:31:22 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id c18so13058274qkc.11 for ; Thu, 10 Jun 2021 10:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=HoMmUzCP4cM1fh13txhJVNc3Q8EsZNHjvCx7OCUbi0k=; b=SvWPgXQy09GQ7RN4UnkcNj1oZCtGBc7nWFZQowaANqzHxjq1NfsKdxhF7lX/iGy6bt JzOiKYYaxxNSEOSOMuIZIe5G2rDprywTguBp1Venfxx5opfFyZf5wDaEgMdNy4rxVpCX bcIZFA/hI2LJRRv8+7pvlFcMuEHJYdDOt8dTo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=HoMmUzCP4cM1fh13txhJVNc3Q8EsZNHjvCx7OCUbi0k=; b=Nv/prPkIrJQg1W97oUx37CbEv8nYUne7XLNhKHTMIEjp7g2V7uV2M/h/f82VsW4537 WynpvbhYG+rNZcZODVopOSn/69hlC2lqK4t66qtK8QSuPFNe7zXlxgSgvdJEFNWT7sJy qlp6p0bt+LgEOY4bq3aLrkfMpiaAi8/WV86KuNcZz4ZkWQLGdKrXHgd/pWjJFdyDw5QX BSOHVDf9aCAlxMeF/aPctJRpBvUCiEazRLwN84Baur+ObPy5XIDsb0hbrT02LrV7E4uM hCNT7Mc3GKKwxb4SttbZwr0AzUfaulUrA4izjZ5zbwfpbiMRngVYY/SWZy0jRFUnflIq Lckg== X-Gm-Message-State: AOAM532Jgy7fP8jAwlJX6mrA0OGKxlTJvQal3EOjdHH4woh1nEbRvrQX GLeFUtGJnasIFFiFccTZOD7rNw== X-Google-Smtp-Source: ABdhPJzTL/BbxgiQ+QHE+DFfEq7TNx22ioA+UWPaow6/4zNmd1YAeXEFkdZwV/T5JEiJhVKtAVURZg== X-Received: by 2002:a37:83c5:: with SMTP id f188mr595036qkd.271.1623346280646; Thu, 10 Jun 2021 10:31:20 -0700 (PDT) Received: from [192.168.2.16] (pool-96-255-231-247.washdc.fios.verizon.net. [96.255.231.247]) by smtp.gmail.com with ESMTPSA id 5sm13129qkj.99.2021.06.10.10.31.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jun 2021 10:31:20 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.49.21050901 Date: Thu, 10 Jun 2021 13:31:19 -0400 From: Carl Wallace To: Sean Turner , Roman Danyliw CC: "saag@ietf.org" Message-ID: <418C66BE-E450-4081-89BD-B04A158D33FA@redhoundsoftware.com> Thread-Topic: [saag] AD Sponsorship of draft-housley-ers-asn1-modules References: <12861641c9f345868f3201bfac6c3db9@cert.org> <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> In-Reply-To: <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 17:31:27 -0000 Inline... =EF=BB=BFOn 6/9/21, 11:03 AM, "saag on behalf of Sean Turner" wrote: Roman, I have but one point to raise and then some cosmetic nits (cosmetic bec= ause compilers ignore whitespace). 0) Point to Raise: re: AllWantBacks. I am not entirely sure whether what is there for swb-= ers-all WANT-BACK merely defines the new value or whether it also adds it to= the list of available AllWantBacks. AllWantBacks is imported from RFC 5912= : AllWantBacks WANT-BACK ::=3D { WantBackSet | ACertWantBackSet | AnyWantBackSet, ... } To add swb-ers-all to the list, I wonder whether merely defining it is = enough. Is there something more that needs to be done to get it into the lis= t as the fourth option? [CW] The swb-ers-all does not impact AllWantBacks. It was simply a shorthan= d means of saying "I want an EvidenceRecord for everything in replyWantBacks= ". See the last paragraph of section 3 in RFC5276. The ExpandedWantBacks in = this draft is a superset of AllWantBacks. Unless I am missing something, I d= o not see a concern.=20 From nobody Thu Jun 10 14:22:10 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FEB3A1A7A for ; Thu, 10 Jun 2021 14:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zGedCiVsDplG for ; Thu, 10 Jun 2021 14:22:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03053A1A78 for ; Thu, 10 Jun 2021 14:22:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3FCEF300BF3 for ; Thu, 10 Jun 2021 17:22:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iMYa3jq8og_H for ; Thu, 10 Jun 2021 17:21:56 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 299CE300B96; Thu, 10 Jun 2021 17:21:56 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <418C66BE-E450-4081-89BD-B04A158D33FA@redhoundsoftware.com> Date: Thu, 10 Jun 2021 17:21:55 -0400 Cc: "Roman D. Danyliw" , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: References: <12861641c9f345868f3201bfac6c3db9@cert.org> <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> <418C66BE-E450-4081-89BD-B04A158D33FA@redhoundsoftware.com> To: Carl Wallace , Sean Turner X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 21:22:09 -0000 > =EF=BB=BFOn 6/9/21, 11:03 AM, "saag on behalf of Sean Turner" = wrote: >=20 > Roman, >=20 > I have but one point to raise and then some cosmetic nits (cosmetic = because compilers ignore whitespace). >=20 > 0) Point to Raise: >=20 > re: AllWantBacks. I am not entirely sure whether what is there for = swb-ers-all WANT-BACK merely defines the new value or whether it also = adds it to the list of available AllWantBacks. AllWantBacks is imported = from RFC 5912: >=20 > AllWantBacks WANT-BACK ::=3D { > WantBackSet | ACertWantBackSet | AnyWantBackSet, ... > } >=20 > To add swb-ers-all to the list, I wonder whether merely defining it = is enough. Is there something more that needs to be done to get it into = the list as the fourth option? >=20 > [CW] The swb-ers-all does not impact AllWantBacks. It was simply a = shorthand means of saying "I want an EvidenceRecord for everything in = replyWantBacks". See the last paragraph of section 3 in RFC5276. The = ExpandedWantBacks in this draft is a superset of AllWantBacks. Unless I = am missing something, I do not see a concern.=20 I agree. I do not see a concern here. Russ= From nobody Fri Jun 11 03:00:45 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35253A3192 for ; Fri, 11 Jun 2021 03:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gyrOtEiyVm1l for ; Fri, 11 Jun 2021 03:00:36 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 4F0AD3A318E for ; Fri, 11 Jun 2021 03:00:36 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id q5so5410597wrm.1 for ; Fri, 11 Jun 2021 03:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eE7oiFUE7xcvGteYSqwU90D+M2RNdg06Kzavtt29Azw=; b=vFK+7knlaLH8339tDnI1ndViyIZd8ckvqIy6B0+T5Oii/CDc9QYysAdRgnGhyWzxQ0 sMokv9/QGMetJSJaSCBwXuPxjA/AWz8D2oigK1S7eXOEsqG2kAOD3gMyWW+Chu87u6aB J0SHD9hfdd+/XBcpuLxGqzfA1wMA/0+KlP2JCECw/57uOTUx/epajPh3a6vrvbbd2v4U kBuLQHaw3WweFrVL57iQwsZM1IX28lEFEmJ5LL22XK5qkkfts1nqWCMRRNsOtJEahHOm yw44vTWX67CRwC9QpvrM7HoCfH9QYSmb49Tc+lu9As8RCgMBX6fyp9/Bjjo+v/0yAbes hvmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eE7oiFUE7xcvGteYSqwU90D+M2RNdg06Kzavtt29Azw=; b=cwHYAd1Bp92bHrTe1cbwspFVcXzzCSeKNwdCrSpy7vVD+KPntHFXFEHD1fW3D+X4rD o7bWRZ7y09wLLfNy3i8kooj5CtT4e43SXWc1ehNSR5GahdrsXDRuUFb+vPCBmS78Nr/t 7iEAbh29jo7WBJSEv2NvWbv8WNJBDWn1K1AWxDH/qwNuTCl/HehjjIluNB8vujJR9tZ6 RpJE86dTvFI90SPowI4IPA2OrK6fAxOR/DmYfAMtJ9IFwjj3CIzCQtN8v2NGt4/c0eDH nOBCj4ZXBt8MunVXJuQEE117kJrfueA1fzqCoklPBMKbHLO/EBJ1bvJNl1c26tdcpbZE 2FAg== X-Gm-Message-State: AOAM532g8ZVgH/txV2Jc4NhoWq58y2V7Fd7BiUggc+uOyzGQpuXqZGf0 UpS77K6+y2noPpLMlvxUf6w= X-Google-Smtp-Source: ABdhPJzgsrM5aploQIct1gM1H1AhSGuzpTfdyymJRcrhR7M3HGaLD6PQbyY4JYun5b+qr2mMwPm7JA== X-Received: by 2002:adf:d1ec:: with SMTP id g12mr3160057wrd.204.1623405633913; Fri, 11 Jun 2021 03:00:33 -0700 (PDT) Received: from [10.0.0.6] (113.87.75.194.dyn.plus.net. [194.75.87.113]) by smtp.gmail.com with ESMTPSA id d131sm12071557wmd.4.2021.06.11.03.00.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jun 2021 03:00:33 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_30012651-999A-4060-BCB3-B96A43BD1347" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Date: Fri, 11 Jun 2021 11:00:31 +0100 In-Reply-To: Cc: IETF SAAG , IRTF CFRG To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 10:00:42 -0000 --Apple-Mail=_30012651-999A-4060-BCB3-B96A43BD1347 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 8 Jun 2021, at 17:36, Phillip Hallam-Baker = wrote: > [=E2=80=A6] >=20 > On Tue, Jun 8, 2021 at 3:53 AM Neil Madden > wrote: > On 8 Jun 2021, at 01:58, Phillip Hallam-Baker > wrote: >>=20 >> =EF=BB=BF >> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden > wrote: >> Unless there is a compelling reason to do so, I=E2=80=99d prefer that = registering algorithm identifiers for JOSE be a manual (and rare) step. = JOSE provides no way for consumers to advertise which Encryption Methods = they support (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so = adding new options here can only harm interoperability. >>=20 >> (This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D= - as these can be advertised in the JSON Web Key metadata). >>=20 >> I don't agree. JOSE has no algorithm negotiation mechanism because it = is a format, not a protocol. After we went through the whole = recommended/required algorithm thing on JOSE, it suddenly occurred to me = that this was precisely none of JOSE's business. It is for the protocols = and services built using XML Signature, JOSE, CMS etc. to decide what = algorithms to require and/or recommend.=20 >=20 > Doesn=E2=80=99t this contradict your desire to have a single IANA = algorithm registry? If individual application protocols are to state = which algorithms to use then they need a registry each to state this.=20 >=20 > Not at all. My point is that the purpose of a registry is limited to = assigning a signifier to one or more signified. It is not for IANA to = specify that RSA is required or not, that is a WG decision. And yet that is exactly what is recorded in the IANA JOSE registry. I = appreciate that you=E2=80=99d like things to be different, but that=E2=80=99= s not the reality today. A WG established the IANA registry and set up = the procedures by which alterations to it are made, as described in RFC = 7518 that established the registry (p34): The implementation requirements of an algorithm may be changed over time as the cryptographic landscape evolves, for instance, to change the status of an algorithm to Deprecated or to change the status of an algorithm from Optional to Recommended+ or Required. > =20 >> JWK is a protocol built on top of JOSE, so it makes sense for that = protocol to specify recommended algorithms. >=20 > This is rather backwards: JWK is part of JOSE and indeed JOSE depends = on JWK (see for example the =E2=80=9Cjwk=E2=80=9D and =E2=80=9Cepk=E2=80=9D= headers).=20 >=20 > Well yes and no, JWK also pops up in other contexts. OAUTH2 would have = been a better example.=20 OAuth2 doesn=E2=80=99t have any dependency on JOSE. I think you mean = OIDC? > JOSE doesn't even specify the serialization format, it is a component = of a protocol, not a protocol. Sorry, what? JOSE defines *two* serialization formats: = https://datatracker.ietf.org/doc/html/rfc7515#section-7 = =20 > =20 >> But the recommendations made in the JOSE spec have absolutely no = bearing on the Mesh which uses parts of JOSE because being written six = years later, the state of the art has moved on. The Mesh does not = support RSA at all and the elliptic curve algs are X448 and Ed448. The = curve 25519 versions are not supported for profile signing, etc. etc. >>=20 >> I would expect the same to apply in the COSE world. Merely defining a = code point for JOSE or CMS does not make a statement about the algorithm = recommendation status. >=20 > Well it does actually - see the =E2=80=9CJOSE Implementation = Requirements=E2=80=9D field: = https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-= algorithms = >=20 > And the reason for this is because the algorithms are implemented by = JOSE libraries. Indeed, this is the whole point of JOSE, that = applications don=E2=80=99t need to implement their own algorithms but = can just use a preexisting library.=20 >=20 > And merely assigning a code point does not change the recommendations = for implementing algorithms in a 'JOSE Library'. It absolutely does in this case. >=20 > Since I wrote my own JOSE library in less than a week, I have a hard = time believing that it is the JOSE part that is critical. And since I = used the .NET crypto as base, the recommendations in the JOSE specs were = not remotely relevant. If you didn=E2=80=99t implement the Required algorithms, then you = didn=E2=80=99t implement a standards-compliant JOSE library. Otherwise = what do you think =E2=80=9CJOSE Implementation Requirements: Required=E2=80= =9D means on an IANA JOSE algorithm registration? >> All it does is specify the one canonical identifier every application = will use. It is not at all important what that identifier is (provided = it is not an absurd length) it is critical that everyone use the same = identifier though. >=20 > If different applications are going to specify different algorithms = then this somewhat argues against your point: they _don=E2=80=99t_ need = to use the same algorithm identifiers as other applications in that = case.=20 >=20 > There is no reason why the algorithm suite for the Mesh should be the = same as that for SIP and plenty of reasons why it needs to be different. = The Mesh uses threshold cryptography which only works with DH and ECDH = algorithms for a start. Even if RSA was still viable from a security = point of view, I couldn't use it. OCB was patent encumbered when JOSE = was written, it is not today. The advantages of OCB over GSM are = significant but not something that is worth losing backwards = compatibility over. >=20 > =20 > But I think we=E2=80=99re rather getting off the track here because as = I mentioned in my first email, OCB would be standardised as an = Encryption Method (=E2=80=9Cenc=E2=80=9D header value). This introduces = more complications. JOSE supports encrypting a message to multiple = recipients, each of which can use a different key management algorithm = (=E2=80=9Calg=E2=80=9D). But the content of the message has to be = encrypted using a common symmetric Encryption Method that all the = recipients understand. This is why introducing new Encryption Methods is = problematic because as the number of options goes up, the chances of = finding an algorithm that all recipients agree on reduces. =20 >=20 > Since I have 0 users and 1 implementation, my scope for deciding = algorithm choices is radically different from that of others. >=20 > You keep conflating the concerns that apply to existing JOSE = applications to the concerns that properly apply to JOSE. I=E2=80=99m not conflating anything. Unlike yourself, I am the primary = maintainer of a JOSE library that is in use in some of the largest = organisations in the world handling many millions of operations every = day. You keep making statements that are directly in contradiction with = the JOSE RFCs. > =20 > (The alternative is that we register as many new =E2=80=9Cenc=E2=80=9D = values as we like but they are all effectively ignored because everyone = uses =E2=80=9CA128CBC-HS256=E2=80=9D as the only thing guaranteed to = work everywhere. This is not the case currently because there are only a = few =E2=80=9Cenc=E2=80=9D options and so most libraries implement all of = them).=20 >=20 > OATH2 allows use of 128 bit AES and 256 bit SHA-2. Again, I assume you mean OpenID Connect, as OAuth2 itself makes no = recommendations about cryptography at all (other than requiring TLS). = OIDC itself defers to JOSE for algorithms. So here you can see that the = choice of algorithms in the IANA JOSE algorithms registry directly and = immediately impacts a widely used protocol. > The Mesh requires 256 bit AES and 512 bit SHA-2 or SHA-3. And that is = exactly what you would expect. OAUTH2 is an attempt to define an = authorization scheme that is conflated into an authentication mechanism = that manages to squeeze itself into the legacy deployed base of Web = Browsers. The Mesh is a Threshold PKI whose primary function is = management of private keys. My problems have absolutely nothing in = common with those of OAUTH2 which is why their algorithm choices have no = bearing on mine any more than TLS is beholden to CMS or CMS to OpenPGP. > =20 > In 2021, I think OCB has very few advantages over JOSE=E2=80=99s = existing GCM Encryption Methods, so I think it is much more trouble than = it=E2=80=99s worth to specify it for use there. If we=E2=80=99re going = to expand the =E2=80=9Cenc=E2=80=9D registry I=E2=80=99d rather it was = for an algorithm with significant advantages over the existing = alternatives, such as misuse resistance or better performance on low-end = hardware.=20 >=20 > This was discussed at some length on the cryptography list and the = overwhelming feeling there was to go for OCB. That was not a decision = taken lightly as it required me to write the implementation. GCM is a = stream cipher and the uses in the Mesh clearly require a block cipher = which means CBC and OCB are the only acceptable choices. >=20 By your own admission the Mesh is doing something entirely non-standard = with JOSE anyway, so you are also free to also adopt OCB as a = non-standard algorithm.=20 As somebody who is responsible for maintaining a JOSE library (and an = OIDC implementation), I=E2=80=99d rather we were somewhat conservative = in adopting new JOSE algorithms. I strongly disagree that there should = be a presumption that any algorithm published by CFRG should immediately = be considered for adoption by default in JOSE. There are cases where I = think adoption would be sensible - e.g. I hope to see post-quantum = algorithms for JOSE at some point - but OCB doesn=E2=80=99t reach the = bar in my opinion.=20 =E2=80=94 Neil= --Apple-Mail=_30012651-999A-4060-BCB3-B96A43BD1347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 8 Jun 2021, at 17:36, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
[=E2=80=A6]

On Tue, Jun = 8, 2021 at 3:53 AM Neil Madden <neil.e.madden@gmail.com> wrote:
On 8 Jun 2021, at 01:58, Phillip Hallam-Baker = <phill@hallambaker.com> wrote:

=EF=BB=BF
On Mon, = Jun 7, 2021 at 10:02 AM Neil Madden <neil.e.madden@gmail.com> wrote:
Unless there is a compelling = reason to do so, I=E2=80=99d prefer that registering algorithm = identifiers for JOSE be a manual (and rare) step. JOSE provides no way = for consumers to advertise which Encryption Methods they support = (=E2=80=9Cenc=E2=80=9D - which is what OCB would be), so adding new = options here can only harm interoperability.

(This is in contrast to key agreement algorithms - =E2=80=9Calg=E2=80=9D = - as these can be advertised in the JSON Web Key metadata).

I don't agree. JOSE has no = algorithm negotiation mechanism because it is a format, not a protocol. = After we went through the whole recommended/required algorithm thing on = JOSE, it suddenly occurred to me that this was precisely none of JOSE's = business. It is for the protocols and services built using XML = Signature, JOSE, CMS etc. to decide what algorithms to require and/or = recommend. 

Doesn=E2=80=99t this contradict your = desire to have a single IANA algorithm registry? If individual = application protocols are to state which algorithms to use then they = need a registry each to state this. 

Not at all. My point = is that the purpose of a registry is limited to assigning a signifier to = one or more signified. It is not for IANA to specify that RSA is = required or not, that is a WG = decision.

And yet = that is exactly what is recorded in the IANA JOSE registry. I appreciate = that you=E2=80=99d like things to be different, but that=E2=80=99s not = the reality today. A WG established the IANA registry and set up the = procedures by which alterations to it are made, as described in RFC 7518 = that established the registry (p34):

   The implementation requirements of an algorithm may be changed =
over
   time as the cryptographic landscape evolves, for instance, to change
   the status of an algorithm to Deprecated or to change the status of
   an algorithm from Optional to Recommended+ or Required.


 
JWK is a protocol built on top of JOSE, so it makes sense for = that protocol to specify recommended = algorithms.

This is rather backwards: JWK is part = of JOSE and indeed JOSE depends on JWK (see for example the =E2=80=9Cjwk=E2= =80=9D and =E2=80=9Cepk=E2=80=9D = headers). 

Well yes and no, JWK also pops up in other = contexts. OAUTH2 would have been a better = example. 
=

OAuth2= doesn=E2=80=99t have any dependency on JOSE. I think you mean = OIDC?

JOSE doesn't even = specify the serialization format, it is a component of a protocol, not a = protocol.

Sorry, = what? JOSE defines *two* serialization formats: https://datatracker.ietf.org/doc/html/rfc7515#section-7&nbs= p;

 
But the recommendations made in = the JOSE spec have absolutely no bearing on the Mesh which uses parts of = JOSE because being written six years later, the state of the art has = moved on. The Mesh does not support RSA at all and the elliptic curve = algs are X448 and Ed448. The curve 25519 versions are not supported for = profile signing, etc. etc.

I would expect the same to apply in the COSE world. Merely = defining a code point for JOSE or CMS does not make a statement = about the algorithm recommendation status. =

Well it does actually - see the =E2=80=9C= JOSE Implementation Requirements=E2=80=9D field: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-= encryption-algorithms

And the reason for this is because the algorithms are = implemented by JOSE libraries. Indeed, this is the whole point of JOSE, = that applications don=E2=80=99t need to implement their own algorithms = but can just use a preexisting = library. 

And merely assigning a code point does not = change the recommendations for implementing algorithms in a 'JOSE = Library'.

It = absolutely does in this case.


Since I wrote my own JOSE library in less than = a week, I have a hard time believing that it is the JOSE part that is = critical. And since I used the .NET crypto as base, the recommendations = in the JOSE specs were not remotely = relevant.

If you = didn=E2=80=99t implement the Required algorithms, then you didn=E2=80=99t = implement a standards-compliant JOSE library. Otherwise what do you = think =E2=80=9CJOSE Implementation Requirements: Required=E2=80=9D means = on an IANA JOSE algorithm registration?

All it does is specify the one = canonical identifier every application will use. It is not at all = important what that identifier is (provided it is not an absurd length) = it is critical that everyone use the same identifier = though.

If different = applications are going to specify different algorithms then this = somewhat argues against your point: they _don=E2=80=99t_ need to use the = same algorithm identifiers as other applications in that = case. 

There is no reason why the algorithm suite for = the Mesh should be the same as that for SIP and plenty of reasons why it = needs to be different. The Mesh uses threshold cryptography which only = works with DH and ECDH algorithms for a start. Even if RSA was still = viable from a security point of view, I couldn't use it. OCB was patent = encumbered when JOSE was written, it is not today. The advantages of OCB = over GSM are significant but not something that is worth losing = backwards compatibility over.

 
But I think we=E2=80=99re rather getting off the track here = because as I mentioned in my first email, OCB would be standardised as = an Encryption Method (=E2=80=9Cenc=E2=80=9D header value). This = introduces more complications. JOSE supports encrypting a message to = multiple recipients, each of which can use a different key management = algorithm (=E2=80=9Calg=E2=80=9D). But the content of the message has to = be encrypted using a common symmetric Encryption Method that all the = recipients understand. This is why introducing new Encryption Methods is = problematic because as the number of options goes up, the chances of = finding an algorithm that all recipients agree on = reduces.  

Since I have 0 users and 1 implementation, my = scope for deciding algorithm choices is radically different from that of = others.

You keep conflating the concerns that apply to = existing JOSE applications to the concerns that properly apply to = JOSE.

I=E2=80=99m = not conflating anything. Unlike yourself, I am the primary maintainer of = a JOSE library that is in use in some of the largest organisations in = the world handling many millions of operations every day. You keep = making statements that are directly in contradiction with the JOSE = RFCs.

 
(The alternative is that we register as many new =E2=80=9Cenc=E2= =80=9D values as we like but they are all effectively ignored because = everyone uses =E2=80=9CA128CBC-HS256=E2=80=9D as the only thing = guaranteed to work everywhere. This is not the case currently because = there are only a few =E2=80=9Cenc=E2=80=9D options and so most libraries = implement all of them). 

OATH2 allows use of 128 bit AES and 256 bit = SHA-2. =

Again, I assume = you mean OpenID Connect, as OAuth2 itself makes no recommendations about = cryptography at all (other than requiring TLS). OIDC itself defers to = JOSE for algorithms. So here you can see that the choice of algorithms = in the IANA JOSE algorithms registry directly and immediately impacts a = widely used protocol.

The Mesh requires 256 = bit AES and 512 bit SHA-2 or SHA-3. And that is exactly what you = would expect. OAUTH2 is an attempt to define an authorization scheme = that is conflated into an authentication mechanism that manages to = squeeze itself into the legacy deployed base of Web Browsers. The = Mesh is a Threshold PKI whose primary function is management of private = keys. My problems have absolutely nothing in common with those of OAUTH2 = which is why their algorithm choices have no bearing on mine any more = than TLS is beholden to CMS or CMS to OpenPGP.
 
In 2021, I think OCB has very few advantages over JOSE=E2=80=99= s existing GCM Encryption Methods, so I think it is much more trouble = than it=E2=80=99s worth to specify it for use there. If we=E2=80=99re = going to expand the =E2=80=9Cenc=E2=80=9D registry I=E2=80=99d rather it = was for an algorithm with significant advantages over the existing = alternatives, such as misuse resistance or better performance on low-end = hardware. 

This was discussed at some length on the = cryptography list and the overwhelming feeling there was to go for OCB. = That was not a decision taken lightly as it required me to write the = implementation. GCM is a stream cipher and the uses in the Mesh clearly = require a block cipher which means CBC and OCB are the only acceptable = choices.


By your own admission the Mesh is = doing something entirely non-standard with JOSE anyway, so you are also = free to also adopt OCB as a non-standard algorithm. 

As somebody who is responsible for maintaining a = JOSE library (and an OIDC implementation), I=E2=80=99d rather we were = somewhat conservative in adopting new JOSE algorithms. I strongly = disagree that there should be a presumption that any algorithm published = by CFRG should immediately be considered for adoption by default in = JOSE. There are cases where I think adoption would be sensible - e.g. I = hope to see post-quantum algorithms for JOSE at some point - but OCB = doesn=E2=80=99t reach the bar in my opinion. 

=E2=80=94 Neil
= --Apple-Mail=_30012651-999A-4060-BCB3-B96A43BD1347-- From nobody Fri Jun 11 20:53:00 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1C43A1BAF for ; Fri, 11 Jun 2021 20:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Jlv-Ti-QraVN for ; Fri, 11 Jun 2021 20:52:53 -0700 (PDT) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) (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 B82633A1BAD for ; Fri, 11 Jun 2021 20:52:53 -0700 (PDT) Received: by mail-yb1-f176.google.com with SMTP id c14so7182034ybk.3 for ; Fri, 11 Jun 2021 20:52:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cPQMhmndeSurZz02e5aIqLSF9L6+yazrn3Y1apcB924=; b=LvtoB8KxbjeECkWmo7n2pTcQQK0ogLAcZlHVxRiy7q3yU8JxKBJNixrqVbAy/rriq2 +ZJ6rYDDASWSWTmEApYF9vzdAyMDsNEVCBzkKLfc8KAZvdgfSJkOKXIA90uUnFoJSAV9 2rrDSxQmGfFgfAlTa1rKe2awFAhO1cfhdHjorpRe3Ru5W095u0838AMnO0lzKZTftfzR 6+tkBaAxbbfcxP7/cW/bkUkTXt9S8n994czWI73nyMLrEzlQEemtQ4se2j2siZpUDd9C 1FGP5dsiNRZklFWCg50rMx11V5gQVCYXQfa9ZZaEtfNNpnivKKnEo3gim2bObqVlOKdP eorw== X-Gm-Message-State: AOAM532VRMi8od509UFnz25UueQo+4WHyZT/5IwMB9Eq6fc8SZ6kYDb6 Tlm80vRW42ld4z67JaiRu1QLOzjMsHwBhU0T8nI= X-Google-Smtp-Source: ABdhPJybJYAotYgKGh4TpLwrGcbD14vOXF6k0e2P08MbhfrTCZ06P0WSJDU6H2d6Ue9wcSlcUtP+jZEcEhpo1mLownk= X-Received: by 2002:a25:660b:: with SMTP id a11mr10189838ybc.172.1623469972744; Fri, 11 Jun 2021 20:52:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 11 Jun 2021 23:52:41 -0400 Message-ID: To: Neil Madden Cc: IETF SAAG , IRTF CFRG Content-Type: multipart/alternative; boundary="0000000000000770dc05c4898f3f" Archived-At: Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2021 03:52:58 -0000 --0000000000000770dc05c4898f3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 11, 2021 at 6:00 AM Neil Madden wrote= : > On 8 Jun 2021, at 17:36, Phillip Hallam-Baker > wrote: > > > > Not at all. My point is that the purpose of a registry is limited to > assigning a signifier to one or more signified. It is not for IANA to > specify that RSA is required or not, that is a WG decision. > > > And yet that is exactly what is recorded in the IANA JOSE registry. I > appreciate that you=E2=80=99d like things to be different, but that=E2=80= =99s not the > reality today. A WG established the IANA registry and set up the procedur= es > by which alterations to it are made, as described in RFC 7518 that > established the registry (p34): > Yes, like I said. It was a mistake. There is no need to compound it. > And merely assigning a code point does not change the recommendations for > implementing algorithms in a 'JOSE Library'. > > It absolutely does in this case. > Only because there is a column giving the recommendation status. My point is that is a mistake. By your own admission the Mesh is doing something entirely non-standard > with JOSE anyway, so you are also free to also adopt OCB as a non-standar= d > algorithm. > It will become the standard if people use it. Which is precisely the point: Code point registrations are properties of algorithms, not one particular protocol that might use them. There should never have been a JOSE algorithm registry in the first place, it should have been a registry of algorithms that JOSE was merely the first consumer of. I remember when the IANA Content Type Registry was the MIME Type. If MIME had made recommendations for supported types, should those have been binding on the Web? --0000000000000770dc05c4898f3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 11, 2021 at 6:00 AM Neil Madden <neil.e.madden@gmail.com> wro= te:
On 8 Jun 2021, at 17:36, Phillip Hallam-Bak= er <phill@hal= lambaker.com> wrote:


Not at all. My point is that the purpose of a registry is l= imited to assigning a signifier to one or more signified. It is not for IAN= A to specify that RSA is required or not, that is a WG decision.

And yet that is exactly what is recorded in the IA= NA JOSE registry. I appreciate that you=E2=80=99d like things to be differe= nt, but that=E2=80=99s not the reality today. A WG established the IANA reg= istry and set up the procedures by which alterations to it are made, as des= cribed in RFC 7518 that established the registry (p34):

Yes, like I said. It was a mistake. There is no need to compound= it.
And merely assigning a code point does = not change the recommendations for implementing algorithms in a 'JOSE L= ibrary'.
It absolutely does in this case.
=

Only because there is a column giving the recommendation statu= s. My point is that is a mistake.=C2=A0

By your own = admission the Mesh is doing something entirely non-standard with JOSE anywa= y, so you are also free to also adopt OCB as a non-standard algorithm.=C2= =A0

It will become the standard if people use it. W= hich is precisely the point: Code point registrations are properties of alg= orithms, not one particular protocol that might use them. There should neve= r have been a JOSE algorithm registry in the first place, it should have be= en a registry of algorithms that JOSE was merely the first consumer of.

I remember when the IA= NA Content Type Registry was the MIME Type. If MIME had made recommendation= s for supported types, should those have been binding on the Web?
--0000000000000770dc05c4898f3f-- From nobody Wed Jun 16 13:53:42 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF6A3A2663; Wed, 16 Jun 2021 13:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URI_DOTEDU_ENTITY=1] autolearn=no autolearn_force=no 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 AAer_MJgFFyS; Wed, 16 Jun 2021 13:53:37 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E113A2661; Wed, 16 Jun 2021 13:53:36 -0700 (PDT) Received: from LLE2K16-HYBRD01.mitll.ad.local (LLE2K16-HYBRD01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 15GKrURm019701; Wed, 16 Jun 2021 16:53:30 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=bEm1GkDH2eqHPyCzcsyax45Q9nyWQO8lAsaiC8diBfViiMkPDBX+L5yo21hqWJCYe64c6JCQVIpai+XQBxV+0N9Z6ezUkHv2VF+7iEeQ5Cr/UbrnYp6B4H4LZO/tGCoq/OfNv6wYQHEW5UPgUtBdT48PKre8iHnSk/2NSQgeoB8cG/Kt9Acw6BREvbzlFC9izNzvD0hU+s3KExNcQ7sevZq+RkIn11Hxlpq9oYlBXip+DZplBL0apczKnqHMSswyfgIEiABK4QW3F1s7YaXoUN+C2apUPp2LSOa0UmsgooaBZ6KQM7a2HU4JDMTnH9DlB7eHGQqQoAAJrnqAM8XHtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q/R12Cc3L+FAR/kqEVBMZ+1zl8Tf5av54Z6in0s1ZZM=; b=QkUPjJL9W5zdfCvz0Iu8zL0m+1Q86pYQJsvlohpVRgB8di2iKudegxFa0VIAgG3rd3W0K4mdTsV/6267iiLg+UzIkjwGTwOvfCQ0ZrjFBEfc7dGoW5IuoCE/cD+FQDUmYgWOolXUxCBiY5KlB+rfOqurNzPA4XL4NUR165Z4PoMp67CQYgnNX21wjmgbjGT88BMv8Vm3bU6tdYhSN6CNffAAQ5ULkVOErS2muZEVlnBdh3TCWImGt9PAucVNgJqgRYgZ0pqNsSkbWT7zWl7UU11VpkJBOSa5Op44qZYlk2wx9Ewz5/KNGgPMiDSQtw7f9qURviHc9OBKdQ+T39G6gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: "saag@ietf.org" CC: "spasm@ietf.org" Thread-Topic: PKIX and related RFCs - definition of Key Packages Thread-Index: AQHXYvGmnmRPUPebfEy9d3ZvsQ8nLg== Date: Wed, 16 Jun 2021 20:53:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ll.mit.edu; x-originating-ip: [129.55.200.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17859c42-a02c-466d-3960-08d93108c906 x-ms-traffictypediagnostic: SN5P110MB0430: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VgEyPdDjw0OxdJBujJ7klH/iJfCmgDnZ8FcY+ld5C4DuY7AH4lFJZKd+61PsHLnSakIRUI6OHpCzKsjNHaDMFOb9RlVPhDdKH4HhgFj02CjRYkNvgQHb9UtsaHbrJhS5522gnu/X6Y7M/HdnEwU0cHz0bl9YBhioEbQCpa0FXoKovmFiTkvHE8lW0noi/Yo2yYCl/KsAvKRdA0MvHSmZcOdGWv4ImmEeFF19aH0TItNUk+xUZi7Yj+Z5fQ8BlB0/juf2rwyF1SdHay908+pHwjNnaDFd0dyigL7sKqH77w7tmobuE7JWcMPDEJuiH+l4kVNRcU31Hov5mb+ewKFSt5ohro7lfGAqSCYNMUq7BpsI1UHTNyvrMoz5/o0hjeXQeOKeIyBBBtsKo8x45apYBjBrijw6vNFIG6X1uMeVA5rbLh1yTXLkvWfm7eeFvA6H3IWOrdzA6bDBI+Hbn6i3epB6zR4kR9xx/t/LRYBKznF/VyTtIJd8LWEFTLgUN7v91kHMqb+7jdIeJBS0IdK4SryFLAMcuR2bU5rR3ujsahDOXRzS7rU8SthCLDKEBFgUjdaMtDZauOpwoflgR6rNGMejwMbzu1rj8tIccb5VCBGZophnAVMkRBCSISF3VgLF6SyWBPb9PbbtWgbB56MVvdpCOMkAfWkZ7W1wlHMPvJr08d7G3CbXLNVN2lWmkz1mqBq5E1wMQOtiU7foxUEbBA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(39860400002)(346002)(396003)(376002)(316002)(86362001)(478600001)(166002)(26005)(66476007)(64756008)(66616009)(33656002)(66946007)(66556008)(66446008)(76116006)(6916009)(2616005)(450100002)(5660300002)(75432002)(99936003)(4326008)(6506007)(2906002)(38100700002)(8936002)(6486002)(186003)(6512007)(71200400001)(122000001)(966005)(8676002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 98IRygVxEfySC0gzswsMP1E7IxvGl1xzFReK+3FvdLXeDk2grVmgV12f8+hICt7iC+R/HbBPXr+2277+Z/khZltqESV1Obpat3Cpl60W46fO8rPbohrzH0HMG0Ux7KXTtqswE0QfnhRjfe2/zzXVJuJH3SOj0ovvepxSbTUVzoh6LhgnxXAHJhpgzK0mGS/ilmWcxMYqlimEkG62eqXo/s8JYPiDbzWAahoDO2XFhMTRwXa89Lz4kTQS/+9BAO4poBT9TcftyhE9UQaLuU8NjqlFZhmNbp2/Hz4tEaOQin9NRaASmmHhcLzPQ9fDoFkqY810yGB+qzWeA8i5kmbINvoCyjOxIr5CNz4ddAkJ+BbcfpOC/wMkgyUgddm0ZOAW5zUKvFC4Y++Mou4NcOsPLY427+6w+f3HmeaMDKWJrPWYNGQpYCs8CL09rFtyOr9THn3XZ8QObjAK3/t4FEQGySZxOenh6bfmdcVS8sMU3vKNLqEoBW5w9iF5UYDS0FCVPANBJg4ECLGq8xT1Tw1n9HgdzzweKbXui4liuOUjdHJ88PBMlrZErUFVLcNuJzZuVWacZuCQp7afVxoIovsGx9cCLI7BgJIlX3uLz6tWuDMNobVUgOP2mTaRfGOMTFntcsS6zbc9EjkfQgpsGTOCszHYhIHr1P0OHmuHl8ScDFvWeUliBcFpn1UlWnUkw3iGnSMkx1N01vl6prQ4jaqMHQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3706707204_536543075" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 17859c42-a02c-466d-3960-08d93108c906 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2021 20:53:24.9834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0430 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-16_13:2021-06-15, 2021-06-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=961 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2106160117 Archived-At: Subject: [saag] PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2021 20:53:40 -0000 --B_3706707204_536543075 Content-type: multipart/alternative; boundary="B_3706707204_584531771" --B_3706707204_584531771 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I confess that until now I never bothered actually looking with a critical = eye at RFC 5958, 5208, 5915 and such =E2=80=93 because the apps that presumably us= e them to interoperate, were already written by somebody else and (sorta ;) = working. =20 Now, as I=E2=80=99m looking at extending those definitions to Post-Quantum algori= thms and parameters, I=E2=80=99m seeing what appears weird to me. =20 A lot of the ASN.1 definitions seem to describe how to package private keys= . Considering that interoperability in the majority of cases is about applic= ations communicating =E2=80=9Cover the wire=E2=80=9D using S/MIME, CMS, TLS or IKE key e= xchange, etc. =E2=80=93 the predominant need appears to be exchanging public (not = private) keys? =20 Yet the definitions invest in the details of the private keys, leaving the = public key as =E2=80=9CBIT STRING OPTIONAL=E2=80=9D. Why is it so? =20 IMHO, first =E2=80=93 PublicKey should be OCTET STRING (probably not OPTIONAL), p= robably CONTAINING {}. Then, each specific IETF-accepted algorithm should ha= ve its own definition of how to serialize its public key, maybe wrapping the= result into an OCTET STRING (usually this is done to allow parser that does= n=E2=80=99t understand the format, to skip this field)=E2=80=A6=20 =20 Is it too late to rectify? And if I=E2=80=99m missing something, could you enligh= ten me please? Am I barking at the wrong tree altogether? If so, where is th= e public key serialization described, if not here? And why not here? =20 Thank you! And apologies for the exhibited ignorance. =20 Here are some examples of what I=E2=80=99m talking about: =20 ECPrivateKey ::=3D SEQUENCE { =C2=A0=C2=A0=C2=A0=C2=A0 version=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1)= , =C2=A0=C2=A0=C2=A0=C2=A0 privateKey=C2=A0=C2=A0=C2=A0=C2=A0 OCTET STRING, =C2=A0=C2=A0=C2=A0=C2=A0 parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, =C2=A0=C2=A0=C2=A0=C2=A0 publicKey=C2=A0 [1] BIT STRING OPTIONAL =C2=A0=C2=A0 } =20 OneAsymmetricKey ::=3D SEQUENCE { =C2=A0=C2=A0=C2=A0=C2=A0 version=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Version, =C2=A0=C2=A0=C2=A0=C2=A0 privateKeyAlgorithm=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PrivateKeyAlgorithmIdentifier, =C2=A0=C2=A0=C2=A0=C2=A0 privateKey=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PrivateKey, =C2=A0=C2=A0=C2=A0=C2=A0 attributes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [0] Attributes OPTIONAL, =C2=A0=C2=A0=C2=A0=C2=A0 ..., =C2=A0=C2=A0=C2=A0=C2=A0 [[2: publicKey=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [1] PublicKey OPTIONAL ]], =C2=A0=C2=A0=C2=A0=C2=A0 ... =C2=A0=C2=A0 } =20 PublicKey ::=3D BIT STRING =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Content varies based on type of= key. The =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- algorithm identifier dictates t= he format of =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- the key. -- Regards, Uri Blumenthal Voice: (781) 981-1638=20 Secure Resilient Systems and Technologies Cell: (339) 223-5363 MIT Lincoln Laboratory =20 244 Wood Street, Lexington, MA 02420-9108 =20 =20 Web: https://www.ll.mit.edu/biographies/uri-blumenthal Root CA: https://www.ll.mit.edu/llrca2.pem =20 There are two ways to design a system. One is to make is so simple there ar= e obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. = - C. A. R. Hoare =20 --B_3706707204_584531771 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I confess that until now I never bothered actually looking= with a critical eye at RFC 5958, 5208, 5915 and such =E2=80=93 because the apps t= hat presumably use them to interoperate, were already written by somebody el= se and (sorta ;) working.

 

Now, as I=E2=80=99m looking at extending those definitions = to Post-Quantum algorithms and parameters, I=E2=80=99m seeing what appears weird t= o me.

 

A lot of the ASN.1 definitions seem to describe how to package private= keys. Considering that interoperability in the majority of cases is abo= ut applications communicating =E2=80=9Cover the wire=E2=80=9D using S/MIME, CMS, TLS or = IKE key exchange, etc. =E2=80=93 the predominant need appears to be exchanging = public (not private) keys?

 

Yet the definitions invest in the details= of the private keys, leaving the public key as =E2=80=9CBIT STRING OPTIONAL=E2=80=9D. W= hy is it so?

 

IMHO, first =E2=80=93 PublicKey should be OCTET STRING (probably not<= /u> OPTIONAL), probably CONTAINING {}. Then, each specific IETF-accepted alg= orithm should have its own definition of how to serialize its public key, ma= ybe wrapping the result into an OCTET STRING (usually this is done to allow = parser that doesn=E2=80=99t understand the format, to skip this field)=E2=80=A6

 <= /o:p>

Is it too = late to rectify? And if I=E2=80=99m missing something, could you enlighten me plea= se? Am I barking at the wrong tree altogether? If so, where is the public ke= y serialization described, if not here? And why not here?<= /p>

 

Thank you! And apolog= ies for the exhibited ignorance.

 

<= span style=3D'font-size:12.0pt'>Here are some examples of what I=E2=80=99m talking a= bout:

 

ECPrivateKey ::=3D SEQUENCE {

=C2=A0=C2=A0=C2=A0=C2=A0 v= ersion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),

=C2=A0=C2=A0=C2=A0=C2=A0 privateKey=C2=A0=C2=A0=C2=A0=C2=A0 OCTET STRING,

=C2=A0=C2=A0=C2=A0=C2=A0 para= meters [0] ECParameters {{ NamedCurve }} OPTIONAL,

=C2=A0=C2=A0=C2=A0=C2=A0 p= ublicKey=C2=A0 [1] BIT STRING OPTIONAL

<= span style=3D'font-size:12.0pt;font-family:Courier'>=C2=A0=C2=A0 }

 

OneAsymmetricKey ::=3D SEQUENCE {

=C2=A0=C2=A0=C2=A0=C2=A0 ve= rsion=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Version,

=C2=A0=C2=A0=C2=A0=C2=A0 p= rivateKeyAlgorithm=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PrivateKeyAlgorithmIdentifier,

=C2=A0=C2=A0=C2=A0=C2=A0 privateKey=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PrivateKey,

=C2=A0=C2=A0=C2=A0=C2=A0 attributes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [0] Attributes OPTIONAL,

=C2=A0=C2=A0=C2=A0=C2=A0 ...,

=C2=A0=C2=A0=C2=A0=C2=A0 [[2: publicKey=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [= 1] PublicKey OPTIONAL ]],

=C2=A0=C2=A0=C2=A0=C2=A0 ...

<= p class=3DMsoNormal>=C2=A0=C2=A0 }<= o:p>

 

PublicKey ::=3D BIT STRING

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Content varies based on type of= key. The

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- algorit= hm identifier dictates the format of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- the key.

--

Regards,

Uri Blumenthal &= nbsp;            = ;            &nb= sp;   Voice: (781) 981-1638 

Secure Resilient Systems&= nbsp;and Technologies   Cell:  (339) 223-5363

<= span style=3D'font-size:10.0pt;font-family:"Andale Mono";color:black'>MIT Linc= oln Laboratory          &n= bsp;          

244= Wood Street, Lexington, MA  02420-9108    &nb= sp; 

 

Web:     https://www.ll.mit.edu= /biographies/uri-blumenthal

Root CA: https://www.ll.mit.edu/llrca2.pem

 

There are two ways to design a system. One is to make is so simple ther= e are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

     &= nbsp;             &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            -&n= bsp; C. A. R. Hoare

 

--B_3706707204_584531771-- --B_3706707204_536543075 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCQIaLeTjg1+pQ3aIJqd8uSv9SBEcNvuIHkkTdi SLe2RDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2MTYy MDUzMjRaMA0GCSqGSIb3DQEBAQUABIIBAHNu9mLHhnr9H4Q66zbIS/HuT281N3VLVdhv7wxB Nvmu6CKLnJFH1k9pw9EHVrtW9U1CGP/lreR6T6X293yWdJWkjH0OYYkYm1EgjORzOP5xIQ3y ivhkK2EjHYwvyfZUIxJHk3VsF+3Z6RZVi2JzseevZlqZBk3qoYic8zUy6I+RdV0GFuDyOV1Q e+gZdajFbrjJHkCMsxygWWyYDaXMoYZQL3yHvS2QuCZA3YTdaYXzv9B0yU/bqAkcL+2iBkOg GpeoCOunTyS728JbehPpKVA24YUwwXGuUS+n1ao741wxzZbkR4Uzw4urwRNy+117FRJlBOJ4 j97PwQbmhuzVulU= --B_3706707204_536543075-- From nobody Wed Jun 16 23:20:05 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D223A0CCE for ; Wed, 16 Jun 2021 23:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 j9xwoMvYkWJv for ; Wed, 16 Jun 2021 23:20:01 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97A73A0CCB for ; Wed, 16 Jun 2021 23:20:00 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2170.outbound.protection.outlook.com [104.47.71.170]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-70--0tQjnidOd6vSOpnGf2P_A-1; Thu, 17 Jun 2021 16:19:53 +1000 X-MC-Unique: -0tQjnidOd6vSOpnGf2P_A-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SYBPR01MB6208.ausprd01.prod.outlook.com (2603:10c6:10:101::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Thu, 17 Jun 2021 06:19:52 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f%6]) with mapi id 15.20.4242.019; Thu, 17 Jun 2021 06:19:52 +0000 From: Peter Gutmann To: "Blumenthal, Uri - 0553 - MITLL" , "saag@ietf.org" CC: "spasm@ietf.org" Thread-Topic: PKIX and related RFCs - definition of Key Packages Thread-Index: AQHXYvGmnmRPUPebfEy9d3ZvsQ8nLqsXun25 Date: Thu, 17 Jun 2021 06:19:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.79.251] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c03853f6-2fbc-4e6f-5b5d-08d93157eac3 x-ms-traffictypediagnostic: SYBPR01MB6208: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: /jd2qpErQKDUHICQ9AVqipFVkeifOISFu49FhYoa131WWwaZ8P/WxRmUguGaFpojH3+B/SV+XDUUm8PUORWx81oCTJcYrFeJ7WdH7fUsyBx10RraGvLQySokUNtOLesPcO7SAlsMs8pwHvUWwK7cvecINbdlpv9xfFb3PJozl4vH5KStt01RACZyAaeDwAqsum2mX/l9EYyLoALvi2bNZ7kvjwnzL9qlw1r8zE0nDCQEhneK4PyqU2lL++d6jlew4pcEZI220aMKz3HvKRLJxHTRB5W1Ba1QSZ9s4ALLLGzT538NpyD0SvADzQQXdTNkXYnFI7FkJULpQ3MQGRwN4sM2l5UdHitVwXit4PIuk0vnqgxlVm9D+j/JfzxUOTFNwezEjWQKTym2JpjMWp8q3fsaJt/bbHJ38nVvslmoq9SFC27Eeu7it8DEzVK4n/z9NGxmIGFmjwXfaRRNtNyf3GlX8LfIpJVurJPbpXrXr37ZtnJx7QQE7zuY8a64WPag22U1W+c7ha9hBMzcabeSpXfo71HLSkMDH7wOmkcUirAxqzULmd6ccWmKHjygwy9Qackrcg6PLen7IxQPDpbB9ACqa0jOZyFuY1qgezyeVAc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(366004)(39860400002)(346002)(38100700002)(122000001)(55016002)(2906002)(5660300002)(478600001)(8676002)(33656002)(8936002)(4326008)(52536014)(66556008)(186003)(66446008)(6506007)(86362001)(9686003)(7696005)(71200400001)(66946007)(76116006)(316002)(26005)(64756008)(66476007)(110136005)(786003); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?owRRSFdXkztd6XblTzIpZcTAG62SLyHUjwCSBrIwqgdTipn3wDiSssZp?= =?Windows-1252?Q?Rbw+oambqJAAXBADO/1B1bINlxznjbEfZ5SGjTFBf7AG6XsGPi5VeSNn?= =?Windows-1252?Q?1IDvyghbrwCxSwTPJw6KLGUCgGwC+KYOEkL2zar6yfn2FPsAHnuGh0Df?= =?Windows-1252?Q?hUHqk++X1Ibxt9VX8IRNlxmv5dBN8hslnFfxTEEh5a7HGFa6+ORkFsRt?= =?Windows-1252?Q?vmgg2ddIPENCFGIu6e5RqF6oKGxyHFeySruZiCn/qgkc86bsqB6dGpo/?= =?Windows-1252?Q?H6vP+tEhaGBmh59llrUf/UvGj7245o4hq6gSQmWUOto1NRZ7vOjCskus?= =?Windows-1252?Q?0Lhd1c6aUrwwMuK8zrv+EULWL+59KKT7lEWDtcojMIZdIm4jn+GJw6ui?= =?Windows-1252?Q?OaVfCSw8kkXzdWlCJk/TruPk3BRZC3qXtZoXseV/KuVQ3xQ0f2eWQXK0?= =?Windows-1252?Q?tcDAS5QtljLXRQWKMnC9x5sW+Oh0R8j2ANSu7+FBxYWI8W8bGAABsDEN?= =?Windows-1252?Q?YAE6qkNoZloh7e+JLAUSBHoxra42Apg/TKsArgAQk/NgudEpX26kyzti?= =?Windows-1252?Q?X0tDjqLn7Wwj3XHE+i6csaoifE5Je6bmvZK79TuwLcJ7nGM1OGMiAMyz?= =?Windows-1252?Q?G2wGyqxosk/XN54O594txFytUETJblg54MsI3gVDTu0ZW8HVi+r+EsSW?= =?Windows-1252?Q?F0ioQkT0kRaYAuk+VvIG5au9SNLyKxfOWhKJOaDat4rBGPuE8NxGYpUY?= =?Windows-1252?Q?jvohC7P0Ug+Kkkz9UrdYUurqUzoEdgvNjRbJQJWzCjHmE5AhzNun/eyV?= =?Windows-1252?Q?/MpLhAv62miUjvFAnbJg1JrOPzWIr4SjAhykXlUDNuTdft3TQRrlDmUJ?= =?Windows-1252?Q?abV0btCIR3nxK0OqICs+7RCxiaSTNv0TvYUdAAPhWUu/vjiYr4A/rnuh?= =?Windows-1252?Q?0DdVcS2/C5NWAOCcuPzUs5HdJDaeZawTmtAMnqsgQqKgDFefo9yzg7vq?= =?Windows-1252?Q?OuDzKX/2PXT7d/jgI0Mr9h4E1CnBL5u++HwjbBOv+u0KtVSf+vbgODyh?= =?Windows-1252?Q?lfiMQnRukK8KGu06iQd/h6UqosTuapH3qYIp9bfwcXafe6YCGIt+GJT4?= =?Windows-1252?Q?OqI5uapqmkzXXLzzo5XvzexObtnLYDimiJ2QoE5ytu7BQnfuKLYdwsvr?= =?Windows-1252?Q?i0V5wIOVj2/lx3q2RcIuTKmUxk/97unIB/EKm1wvDfhAL+16dklo8pjC?= =?Windows-1252?Q?U9hBszyBVNeoEQV6rSCHbkbpti7VNYhseGW+khip6Jf9naYu1Kk4EBMw?= =?Windows-1252?Q?AdstK9891CzmXRiH77GDNjUciWGK+Qn8grBEibC1/yHYNbSpILC0LuZ/?= =?Windows-1252?Q?YO/j4FXtCfEjNQcH9qf6gM9OuOR9Pz4Vo6E=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c03853f6-2fbc-4e6f-5b5d-08d93157eac3 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 06:19:51.6957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5yWDTJVv9DMXvYZIvxqD19w+yEwGdx7OEWHITD4eTNJltNq3LwQDoIUTiU/8FmM0o+oEscKmILu08S7V0EghiEI968je3QR4J26bHuKcSiA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYBPR01MB6208 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 06:20:04 -0000 Blumenthal, Uri - 0553 - MITLL writes:=0A=0A>Yet the defin= itions invest in the details of the private keys, leaving the=0A>public key= as =93BIT STRING OPTIONAL=94. Why is it so?=0A=0ACargo cult protocol desig= n. Back in the late 1980s someone decided that holes=0Acontaining keys had= to be BIT STRINGs. So today, thirty-plus years later,=0Aholes containing = keys are still (mostly) BIT STRINGs even though what's=0Apresent in the hol= e is always an OCTET STRING.=0A=0A>A lot of the ASN.1 definitions seem to d= escribe how to package private keys.=0A>Considering that interoperability i= n the majority of cases is about=0A>applications communicating =93over the = wire=94 using S/MIME, CMS, TLS or IKE key=0A>exchange, etc. =96 the predomi= nant need appears to be exchanging public (not=0A>private) keys?=0A=0AMore = cargo cult protocol design. PKCS #8 specified the format for RSA private= =0Akeys but nothing else, for the simple reason that there was nothing else= at=0Athe time. Then when people needed to store something other than RSA = keys they=0Ainvented their own formats extending PKCS #8, principally led b= y OpenSSL (who=0Ahad the most need for it) but occasionally other vendors a= s well, whoever got=0Athe most mindshare first. The issue was resolved by = PKCS #15 which specified=0Aa general format for public and private keys, bu= t everyone ignored that and=0Ainvented their own new format for each new pu= blic-key algorithm.=0A=0AAs a result, when you write an RFC specifying the = format for public keys for=0Aalgorithm X for, for example, S/MIME, you also= need to specify the private-key=0Aformat even though it has nothing to do = with S/MIME. Rot bilong kago.=0A=0A(And as a general note, a lot of the WT= F?!!? stuff in PKIX is explainable=0Athrough cargo cult protocol design, it= 's not just these two).=0A=0APeter. From nobody Thu Jun 17 06:07:13 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951493A1F0E; Thu, 17 Jun 2021 06:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 hKwBY7hRC9IX; Thu, 17 Jun 2021 06:07:06 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABE33A1F0D; Thu, 17 Jun 2021 06:07:06 -0700 (PDT) Received: from LLE2K16-HYBRD01.mitll.ad.local (LLE2K16-HYBRD01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 15HD6vd9003207; Thu, 17 Jun 2021 09:06:57 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=tChPvZrviKvkwzUEoh+nWD4Y5F/Dg0VxiXkd7hARzXnW62+OHHVxKOIYzREGZ6OGVXMmyWERQ13O9GTaJp7cEkB2GOMwfyPvssbqv/G+JQ/i65In/31gXUOQG7UW6/iAzLFYgJwC6sEREWBFWCSjj8r/jcOIzY8Ysin/mWR1FfKbx0j5r+ORExujxvBgJZO0OHDJ7CUVuJPkUGDJqIB8gPSfz0+l/zWyqSHuAJJnZ2MeZSX4s+pcMOn+hWbpCixH1WrYSOC+aqLVtdO1c+Wj4gCTwG6X2+4D3/Ovp8v14otECZmjxat+G5aFOZLIhbNnqyn7m3UTHDpbjMPYSanULw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m70u6aesdx+v/4KUzt2nyAuAQbHSemqRlwK4yCj+GoM=; b=uyM/q7x9x0VlFD9Ys7YkakmQg+JNQ/bExHaLQI0EoB1Uxbj0/dz2z3B38FNqj3AnAN/qtlHiYsRycmMtK3rVPwtR9Itn4G6leHVeGIW5pSI79BLGTgfkyZiPzmRZiNGu5qbCMGyBnaGOZOC42Dv2fUEQ4wJfdWPet7FOs+kSNDDHlnVoDVRViALBPTRX1BiAhC3G1ePZOPy5BjMM2+xt5nVvhNg2Ttu1aAqqhPuL/TTK3ToVPsl9eLm2ByOmlxxwnJGvhQlQAl3jeLa/QSoeR9w2qPafMo+TgTb9C8VBGdFLw7+IXld6iuHEQC4PwS2/R6SF4Yp1bQLcvD5hbEd9pQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: Peter Gutmann , "saag@ietf.org" CC: "spasm@ietf.org" Thread-Topic: PKIX and related RFCs - definition of Key Packages Thread-Index: AQHXYvGmnmRPUPebfEy9d3ZvsQ8nLqsXun25gAAv0QA= Date: Thu, 17 Jun 2021 13:06:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; dmarc=none action=none header.from=ll.mit.edu; x-originating-ip: [129.55.200.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3af791c3-dabb-41c7-1884-08d93190c55d x-ms-traffictypediagnostic: SN5P110MB0574: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 26mx6zPyOj/MkRXe71GaJKmLgJr0I6UBNr+oVNbbsZS8I2wg6CCRMG7IBCvPAW2uFQ8VG0aE2OfMFG3wrZfw6a1M04FRBhi5LweGqpZPSaZalcplokhbwMYXdAmVN9EcKZK9zDnBumdjJdByhN5NWdcUKup81nbsm5n/DEpfa+rGlHPar2COFjYnbnyrkYpLieRQbOAUTgM9GPHK9ey6Zi8OTFHEghIrhnqwRZLoX25WL5Cu2ebJT3IxFTuzpgATRNStZa2aG1bLgofOy2OnBD+C2SQ8jQ0H8wxlTRM9SmkkprtDI5YCsDn50tOTqjIy4CLIGd8EoR+cnRi79DWnh7J+4wzWUVhmE53hJAh5n2ZUEt1rlSqBg8XCMwqU0D+sqgZb91uRonGoZcMMqDYN2WoP3/hRVS/JZzv6949lUnkeqKHP0/3GuieiH57ONkLU6jDcjIHm3jJfCfNDTtTD55J8fGoVImwsfSuvgvdWlmeWnq83ZugXeKsGgVT5sms0bBhh186/h/apu1gSc/AwIAnt8bjw6aX+6rOBSJ3geO9GygEEHxSeASsw93JQVlLLC1w/Z8+iizIx5M7Bgv6U+Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(346002)(366004)(136003)(39850400004)(33656002)(6506007)(8676002)(122000001)(75432002)(38100700002)(86362001)(66446008)(66476007)(76116006)(8936002)(64756008)(66616009)(2616005)(66946007)(71200400001)(66556008)(478600001)(186003)(110136005)(6512007)(6486002)(4326008)(316002)(83380400001)(26005)(99936003)(5660300002)(2906002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: acJhJGW9A8sllkO64T9rO2/VCI3Fv03QyAfRN/K/y0sSzMuImn3/Lt7/O0cmUJUpNXd4J05IKHtr1SaxXWQF+P6L7KvKwJ5CA3MvGWsL9PCrczld4Atvod9+9n6HSre1Xef5r89Cq6LyfisIvteuhiXZP5sVfvFulmHdiZoW4lSHAzjcYDaQxvzqrjJjg90WBsba/mXNS1qkaAtk6vB79izO+0OfuQ+vVkNxamWSV/jo7R6wCr+XHV25HpHOJFY6OIDoUpF6MUqwZ/CV6mvwiIxAcS+SKqb6Y0CpWrq4CUeizHlNESeDai9YK3TV5lnlonxeAV6bZ9uK/uv/F5cxyGzmWZvMJYKFvz763Ddx81UBA/LXuqh4nfBJJ8y4oaYnV+7aV9E8moBryTdg6gF8vKzRwj4cITFuGWqbetqoOOFdEd4NKwhSiUeuiP8oJfTYTvDQ8WfrNnzXXhOX4fu6JOIaPVYPV4Yi0UDimBPNtw2ogedEAtg04VbXe2iz5WwSDpKMx1HIaejhMBjUB7ntlDcY92vN9KiSOqrhoS0709OQUG2YexI5TyaIjqbc+iiBCDuIHLYTM9/kZykELjZnqBe8KbILj+ccO5t3Ygk4oxbcXQnvEKsOnitWa0P090PItS2DRk4TlTZb+nybtfGWxrQG1UERcND8X6z3ACQ08w/kaYwziz7xXMPHaHVfRg6IWXVWA19zYFd5R0wrDrGxBg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3706765606_549334807" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3af791c3-dabb-41c7-1884-08d93190c55d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 13:06:50.4030 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0574 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-17_10:2021-06-15, 2021-06-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2106170085 Archived-At: Subject: Re: [saag] PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 13:07:12 -0000 --B_3706765606_549334807 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > I think the short answer is that public keys are usually exchanged by sen= ding certificates. I'm not sure I understand - private keys usually are not exchanged at all, = and yet there's a whole bunch of ASN.1 stuff describing them. > Raw public keys that are not associated with an identity can lead to subt= le security > vulnerabilities (Mallory swaps Mallory's public key for Alice's without B= ob noticing).=20 This is supposed to be not about what good a standalone public key is - but= about how to represent and encode that public key in an interoperable way. = Whether such encoding makes sense outside of any context is a totally differ= ent question, which to me seems irrelevant to the main one - how to encode a= public key that is not a simple big integer. > Sorry to be the bearer of bad news, but you may be headed for a serious e= ncounter > with X.509, e.g., via RFC 5280. That is indeed bad news, but on the other hand - a good start. __ > >Yet the definitions invest in the details of the private keys, leavin= g the > >public key as =E2=80=9CBIT STRING OPTIONAL=E2=80=9D. Why is it so? > > Cargo cult protocol design. Back in the late 1980s someone decided th= at holes > containing keys had to be BIT STRINGs. So today, thirty-plus years la= ter, > holes containing keys are still (mostly) BIT STRINGs even though what'= s > present in the hole is always an OCTET STRING. Excellent. That means there's no hidden wisdom in there, and I can (and wil= l) in my design revert this to what Common Sense suggests: an OCTET STRING C= ONTAINING the specific format/encoding structure that a specific algorithm (= e.g., lattice-based) would require for ensuring an app can correctly decode = it in an interoperable way. > > A lot of the ASN.1 definitions seem to describe how to package priva= te keys. > > . . . [though] . . . the predominant need appears to be exchan= ging public > > (not private) keys? > > More cargo cult protocol design. PKCS #8 specified the format for RSA= private > keys but nothing else, for the simple reason that there was nothing el= se at > the time. . . . > > As a result, when you write an RFC specifying the format for public ke= ys for > algorithm X for, for example, S/MIME, you also need to specify the pri= vate-key > format even though it has nothing to do with S/MIME. Rot bilong kago. Hmm... What would happen if in a new document I choose not to specify priva= te-key format...?=20 Given the fact that it's (practically) never present on the wire, and compl= iance/interoperability for its implementation cannot be tested? > (And as a general note, a lot of the WTF?!!? stuff in PKIX is explaina= ble > through cargo cult protocol design, it's not just these two). I see. Thank you very much for explaining - unfortunately, it makes a lot o= f sense. =E2=98=B9 On the other hand, it seems to mean that (due to this lack of definitions) = there's nothing to be backward-compatible with, so one can (finally, hopeful= ly, maybe) do it right... Thanks! --B_3706765606_549334807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCACfYnqG66JLH2c392oAJS0JzCIQyqtmaaH4EOG D7YylzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2MTcx MzA2NDZaMA0GCSqGSIb3DQEBAQUABIIBABqnpxZbWx5KRPR1HVRdQbCPq7NNfNtJPO94P9bo ryeSv9CGshgy+g7orkixAB/Bd/M2x7uGgNmYy8A66BdLcZO8wxFR37iTp4b0IMGXOpwvVeYd lr1q9bGpGL9l0yFmgwiBWhFD4P7Wc5KJipIi82sRd+bLOYySs/HTziXCqVbTOwHkfJXM3oMq Oov2L8uw+gezJmkYUQQqa96WYptR+UtwbB/H4KGwYPkLx4uBj7LKB1jjh0t/Gud89ewFswFO OiB/pOCGPnsxyJwQx8UjAHSsc53k+Yqpk6yMOuFIWS+yIbchmMYNN+chA/nQrewywPNHHsBr yzl1k4P8By6sY10= --B_3706765606_549334807-- From nobody Thu Jun 17 06:21:10 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67F93A1F69 for ; Thu, 17 Jun 2021 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 uGGTmLYwav8x for ; Thu, 17 Jun 2021 06:20:59 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E915F3A1F7B for ; Thu, 17 Jun 2021 06:20:58 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2233.outbound.protection.outlook.com [104.47.71.233]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-35-KAijYiDONkakbMdSKncy-A-1; Thu, 17 Jun 2021 23:20:53 +1000 X-MC-Unique: KAijYiDONkakbMdSKncy-A-1 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com (2603:10c6:10:10b::10) by SY4PR01MB6329.ausprd01.prod.outlook.com (2603:10c6:10:108::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Thu, 17 Jun 2021 13:20:49 +0000 Received: from SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f]) by SY4PR01MB6251.ausprd01.prod.outlook.com ([fe80::51a7:5858:c7ef:880f%6]) with mapi id 15.20.4242.021; Thu, 17 Jun 2021 13:20:49 +0000 From: Peter Gutmann To: "Blumenthal, Uri - 0553 - MITLL" , "saag@ietf.org" CC: "spasm@ietf.org" Thread-Topic: PKIX and related RFCs - definition of Key Packages Thread-Index: AQHXY3t/WcgDSaQfh0SQdLtLUWkjSg== Date: Thu, 17 Jun 2021 13:20:48 +0000 Message-ID: Accept-Language: en-NZ, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [14.1.79.251] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93818d07-434b-4fdd-35ec-08d93192b936 x-ms-traffictypediagnostic: SY4PR01MB6329: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: /kNZ0jefnIfNhIFO5YB7CGl6u78+O8iFf7VBQSEx2ZpSN/VkmDGTPBiWvNA2t36IlYxh51OrNwJgCY967SY5Idem6y/aGHZyndDpYAJS8w1W/aCh15sk++t9a0pco6OUH1KFtYunmL/DsirM63g4tGzqJDjMAs6dJjtItKkPLeULLytjE+mGSklARfMboK2ZV8SvnOtMWqP43otssFDVsp63ht9pSJm/elc5eeYTzowfRYth3rJdjfsc1iWwSeh8QRzYrjIZjAYQ4qLWPotDiKDvipPeQfyKAKK9wktt75vl2BG1MkXpJP51r9MDWmAX+jeoLoD/swJSkEGy+Ycgl6aSQceFF9Kp7CRqay0YGqXuayJX75u/lq4UOcdi8eD8fnm2LQeGhWVDMb/XOMCza6hubThFrfFtb9WEWTvAqGQ3px7bUhIVvQeCRdHVIK1CemNlaNUcdYDIG/d0N0BHrARViRbaGjR+i/wukQA5d67XreY+Ow87lqTdJ9twr29X20b+3UNnkzOg4oy1EhuBD1pIdZbWa9LHGdp/rZQFKFYQaPa0p/jGppJqSMRcogMrNBMdII4m2mQql2rmvUNF9GkuA3Ql355/XnuxRH026b4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6251.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(376002)(366004)(39850400004)(66946007)(66446008)(64756008)(66556008)(66476007)(4744005)(110136005)(4326008)(2906002)(38100700002)(122000001)(76116006)(71200400001)(8676002)(8936002)(83380400001)(86362001)(6506007)(786003)(55016002)(5660300002)(26005)(186003)(478600001)(316002)(52536014)(45080400002)(7696005)(9686003)(33656002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?tO/oZ5pLulxKk075lyPYRzHlbZnvNhFPrf7xW0+S2FF/680LJYSlwoFCKN?= =?iso-8859-1?Q?JQ4CmHUETPA75DTffLHrjbzQc64ixc8tqQ2Rg/HZQHgnGAeMXZXWSODlyL?= =?iso-8859-1?Q?xf5nBnvKHWOw4NjxI7cRlPZfbGLtfJJwmmK7V3ZtFfhx1kWG1avL1xBM+7?= =?iso-8859-1?Q?0HUO8/iG+z44oF+f0cpOofudFU8DJpkueknQ2d9Oh2ooDaPrHljmwcNCUd?= =?iso-8859-1?Q?9Ga0XSNpQERxazevqNRdBAdr6xD+9PKnklJhS1XF4NZuVoKmwR3JOZSbuc?= =?iso-8859-1?Q?/VA/wQD7C5SOVKz1jb/MBR0NfOsG//zd/+xT+cmjZI6aQZQ9SWeam8D+Y9?= =?iso-8859-1?Q?JBNiq/3csX5XLd3nMD19dvEm56R/9txnMHPjbUXC8v+VqEkXVwCMWyZ9ji?= =?iso-8859-1?Q?SDIsO69tPXIW91yphBKaKUYDS5NeSPtcpkp2kdLAs7UKc48dsQ0tQeyVYc?= =?iso-8859-1?Q?F7LQTrWOusWJDNcuMBKCl3pMS48uktiZ3rbQ3SWXqlfthWFo4LdSlVlC2w?= =?iso-8859-1?Q?gHouQECzDFfX+wqcX21IEhRiAF6iscSGo/yWpsZ59eUqyOb8EKBlQgVGRk?= =?iso-8859-1?Q?THyul/ghUdXxM2IdvzI1tJGfccVsvCyYgt4m9mRbIdeHacBwmNJWxmLFn6?= =?iso-8859-1?Q?8eqjhsLDInf/a1gphL5n/hUm9JKOQ2xIwA0cEJrih0L1t2/Gzbeqxv1u7+?= =?iso-8859-1?Q?i43H/HE9o1XbH3sEFMxkhfqxv0ReHvwTLMhrkWAaba1BQ/mldO95LeaUE/?= =?iso-8859-1?Q?eZjWKgcY+A29Rg5K/upFTygF+I6e4crfvk2WFCmyqrf1o2GikO2Cy1Mor3?= =?iso-8859-1?Q?eSTsDeSpWd9p+kjdn2n5oIHWATM6OmFUJKY422ayzP2hVn47lNIgymkSEz?= =?iso-8859-1?Q?DxMoiNzh1v/u+gzOtfDtPL0qe0RDoknhM4T9Qx9KxaBWlJD3+kUKuWaX1v?= =?iso-8859-1?Q?vsv3EG/5TSjnqzc41Ha3vwidJi40kyjvpVVcWhDhXIy6b+ZuxFCDPA6FVE?= =?iso-8859-1?Q?Af6bqY5B9ryr+DST7MmLwtLZdiP+zLRMrF1VQFXFuHP5ERZZNTFwMNMExc?= =?iso-8859-1?Q?uZePhetvv3ZSUy625++lRkFYdryniXAaU4A8/s1VonG2Z1dUbLDzsuZfk5?= =?iso-8859-1?Q?gBGsRBwwSe7aKoxt+/GW5UBqrq98mCPnsAe8H21V2EOv6QOLahNo+pi+0G?= =?iso-8859-1?Q?6MQUumER9tTe4ees5SyIGKeh/xxTH4OdO4hNSn+zY6v9xd43yfIX3XKmCm?= =?iso-8859-1?Q?o4aVDTkRFNAE7cBIM6CdjSQ0p/B5a9eavMaNCtv/84h9fZPO1JnkErCsWs?= =?iso-8859-1?Q?QhHZZ+aNgQt74Jt9yQIlMSdNx2F0+3bzAajEyQ7WKy6CY1o=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6251.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93818d07-434b-4fdd-35ec-08d93192b936 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 13:20:48.5886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P3LZiXH/GMDKA9AXgt+I+pIx89wPDUYNPfDdP7UM17dcErqFvNIHs1Hvh31uJZm4Vzlr8HTaDWoADxAaT9pV/bXwGP0xSVFqOBmd/VSZHko= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4PR01MB6329 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 13:21:03 -0000 Blumenthal, Uri - 0553 - MITLL writes:=0A=0A>Hmm... What would happen if in= a new document I choose not to specify=0A>private-key format...?=0A=0ATrad= itionally, somebody would invent one and then whoever shouts loudest would= =0Aget their version adopted. Mozilla and Microsoft (at least, and possibl= y=0Anowadays Google as well) would implement it in a subtly incompatible wa= y so=0Aevery implementation would have to guess at what it was they were se= eing.=0AEventually it would be documented in an appendix to an RFC on OSPF = extensions=0Aor something, but by then everyone would have deployed multipl= e-format parsers=0Aso it wouldn't matter much.=0A=0AOr you could look at PK= CS #15 and document it in a format compatible with=0Athat.=0A=0APeter. From nobody Thu Jun 17 06:51:08 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6E3A2072 for ; Thu, 17 Jun 2021 06:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no 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 2cMK3K4viB9X for ; Thu, 17 Jun 2021 06:50:54 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFAA3A2073 for ; Thu, 17 Jun 2021 06:50:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E15FD300BB1 for ; Thu, 17 Jun 2021 09:50:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Qrp2qj2p5CEv for ; Thu, 17 Jun 2021 09:50:48 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 7B736300231; Thu, 17 Jun 2021 09:50:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: Date: Thu, 17 Jun 2021 09:50:45 -0400 Cc: Peter Gutmann , IETF SAAG , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6CF9941B-2B02-467B-BC07-B6DD6E5FC6D0@vigilsec.com> References: To: Uri Blumenthal X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [saag] PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 13:51:01 -0000 Uri: >> I think the short answer is that public keys are usually exchanged by = sending certificates. >=20 > I'm not sure I understand - private keys usually are not exchanged at = all, and yet there's a whole bunch of ASN.1 stuff describing them. Yes, this is needed. For example, PKCS#12 can be used to move a private = key from one device to another. Russ From nobody Thu Jun 17 14:19:54 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE103A2E7C for ; Thu, 17 Jun 2021 14:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 DId351adPOvS for ; Thu, 17 Jun 2021 14:19:46 -0700 (PDT) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 EAFA53A2E7D for ; Thu, 17 Jun 2021 14:19:45 -0700 (PDT) Received: by mail-qk1-f169.google.com with SMTP id f70so5698644qke.13 for ; Thu, 17 Jun 2021 14:19:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=6NuDJtGqK/UwB5IGQuexvPAPD7EvDY4TE82XLaUqRx8=; b=J74zgqGPAs33g+uFy1fBzy8yCrcZVe2hy/huJjLr+HOoVZ1ZTTQxHX5oMc8QxZJ3a3 9+rh6sX7epSUMtFwXxuJ1jVSEU9FSvirpksTl8xThuqiTma58LHZB+KbYQ9KLqc61oRK PV7iRYePyWRuxTrYhskUFtoancCkv+7RpbiD4/4tRCDBpMs86UQfUw6Jsaip9NqIHHin /z7z/eCVJGTVfovyQNcS4o127p4u4xPoqlT1qWLthSfnBkZ/YHIXQ66n6kZlrmyZWekY /tR1lN0/cgDFx9xbFsFwktprBYgQxy8C/we3KmbenB9nKkHNtI2jGn//gjBDMtzNn489 jXCA== X-Gm-Message-State: AOAM531z/kHJisfcrqWCrt7ocJEGEoAdLHxVbYmkvxKAHFEaLY5ITSh4 FDkslBXpwshp27oUKvz0Qt2Q1tXk8J9q1Pky5tarN2UEhDM= X-Received: by 2002:a25:6910:: with SMTP id e16mt9192703ybc.523.1623964784600; Thu, 17 Jun 2021 14:19:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 17 Jun 2021 17:19:34 -0400 Message-ID: Cc: "saag@ietf.org" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001f39e505c4fcc455" Archived-At: Subject: [saag] META Re: PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 21:19:48 -0000 --0000000000001f39e505c4fcc455 Content-Type: text/plain; charset="UTF-8" I agree with much of Uri's frustration here. My concern is the meta level. If LAMPS is going to ever close, we have to make sure we are not going to need something similar in future. Which means that we need to define what is required to specify a cryptographic algorithm so it is available for use with IETF protocols. Note that adding an algorithm to a registry does not mean it is approved for use by a particular protocol. CMS serves a much wider audience than S/MIME. PKIX, a wider audience than either the WebPKI or PKI in general. Same for JOSE, XML Signature and Encryption, etc. etc. So I conclude that one of the exit criteria for LAMPS should be a document describing the list of things that need to be specified so that an algorithm can be used in various specific IETF protocols and conversely, what applications using the IETF maintained IANA registries can expect. I do not want to get into discussions of why the decisions of some working group ten years ago on algorithm requirements should bind some other group doing something different today. HTTP is not based on MIME but it uses the same IANA registry. That is the correct approach in my view. Going forward, I see no reason why it should be necessary to specify separate identifiers for the use of a particular algorithm in every different application protocol. The ASN.1 world is going to need OIDs for quite some time and the JOSE world is going to be needing text based labels. The XML world consumes URIs but there is no reason we couldn't specify a URN prefix to the JOSE labels and use that to avoid further maintenance issues. TLS and IPSEC both operate at a layer that is sufficiently deep that we should just let them do their own thing. And PEM probably isn't much of a concern going forward. --0000000000001f39e505c4fcc455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= gree with much of Uri's frustration here. My concern is the meta level.= If LAMPS is going to ever close, we have to make sure we are not going to = need something similar in future. Which means that we need to define what i= s required to specify a cryptographic algorithm so it is available for use = with IETF protocols.

Note= that adding an algorithm to a registry does not mean it is approved for us= e by a particular protocol.=C2=A0

CMS serves a much wider audience than S/MIME. PKIX, a wider audi= ence than either the WebPKI or PKI in general. Same for JOSE, XML Signature= and Encryption, etc. etc.

So I conclude that one of the exit=C2=A0criteria for LAMPS should be a do= cument=C2=A0describing the list of things that need to be specified so that= an algorithm can be used in various specific IETF protocols and conversely= , what applications using the IETF maintained IANA registries can expect.


I do not want to get into discussion= s of why the decisions of some working=C2=A0group ten years ago on algorith= m requirements should bind some other group doing something different today= . HTTP is not based on MIME but it uses the same IANA registry. That is the= correct approach in my view.

Going forward, I see no reason why it should be necessary to specify s= eparate identifiers for the use of a particular algorithm in every differen= t application protocol. The ASN.1 world is going to need OIDs for quite som= e time and the JOSE world is going to be needing text based labels. The XML= world consumes URIs but there is no reason we couldn't specify a URN p= refix to the JOSE labels and use that to avoid further maintenance issues.<= /div>

TLS and IPSEC both operat= e at a layer that is sufficiently deep that we should=C2=A0just let them do= their own thing. And PEM probably isn't much of a concern going forwar= d.=C2=A0

--0000000000001f39e505c4fcc455-- From nobody Thu Jun 17 15:08:28 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822823A3066; Thu, 17 Jun 2021 15:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NNex2PgOtEdt; Thu, 17 Jun 2021 15:08:11 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2859A3A3063; Thu, 17 Jun 2021 15:08:10 -0700 (PDT) Received: from LLE2K16-HYBRD02.mitll.ad.local (LLE2K16-HYBRD02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 15HM85qh041416; Thu, 17 Jun 2021 18:08:05 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=rSx396oQLyNq5uvzmMoUf/HKbkpOG2kSQvBilfFvg8EsdI/NSh35bPWhwul2kHufn9R8dV01XVwP4KIP7V21G5hoOBfxGW9iB9JFFTsGW750orhJvb0uWuqjM+n9BuAgrVuY0hjuUwL1pdWAF60rktufYQh2EUU5xGzykekiKzFgr0v3NieAArlQeBplZ2Fa9S5S8e1/Iam8d8DNJk9lyBFY7plh5JN9lmOjowIvUWcQ0+upS2KkNt9eqnv28pPfVqi5Ukn+LupP0NZKxhIeTSyBxy/ykuzBC7r4zRt0Lt1mUmraNLMtiqQ22wPhwLGeW19tTatJUuCQiK8scTeNFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KrfPscqhMrTiw1NFButoAAfld5zNvaHngIKudFz59KQ=; b=B3EV236mOQxvUzkY+TA75VWWPr1qILfuKObYdXxxVIsAwKVkc8OT0ZvUkAgQ5oiMOaQA0M+p971SciFamssuY6xSetzym5E16inZ9WdZUP9DTkQQ//450kII4y2yi+eIMFMjWazXUvT96XpardDsaUy38F23G13EO/zmSt3WAqwbLhkd9WPmc27JU7nHZwcDwwU0Xop6PncMANuvNE0JbeW3lqf3tCfeFpmqy9lq05QzvKEttYwTP00csTqDafsBncHfQA6zQLw+C9aJavRHdeexh+D6PGIXoa2HaQFuhoYtTf3YMd5PVL6o9P/ngD0jjVjA7YGFbDhVGrWpn0Wp7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none From: "Blumenthal, Uri - 0553 - MITLL" To: Phillip Hallam-Baker CC: "spasm@ietf.org" , "saag@ietf.org" Thread-Topic: [lamps] META Re: [saag] PKIX and related RFCs - definition of Key Packages Thread-Index: AQHXYvGmnmRPUPebfEy9d3ZvsQ8nLqsYtwwA///KMoA= Date: Thu, 17 Jun 2021 22:06:59 +0000 Message-ID: <9E283165-E2BF-4719-8BB7-BCA6B70C356E@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: hallambaker.com; dkim=none (message not signed) header.d=none; hallambaker.com; dmarc=none action=none header.from=ll.mit.edu; x-originating-ip: [129.55.200.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11e0a032-6d22-4dc4-895b-08d931dc3af4 x-ms-traffictypediagnostic: SN5P110MB0528: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xDwLDhEm67qQ5kxPmm94+V1gA1G5ykimq/0pZRwQsaq53RJHKPCEse5bmXjgexnjSPCu/p61c0UbBcLv82oMe3f+QRCf7ABm+csqnkhMT3HLyUnm1xcRA3H4ibXoQkY7R2AvmY0BefBtEtbAZoYsT+q3CJWkVo9AV5gC3efji4Slrr+wURwINwm7u1rP1KdMSPy1Y6ezfA36hVFelB1+hIjmCOnCfLX9tiIypB9IN7d7914BlKk4FmgBMSpDKYoO+zT/rNGYRSz8LFm9D4H3jB0j4KM59DS7fYOt6iQbhsOxzk0/jPU6rGCFQnPC6CATsyc4d+9NeMR7rHgw5TLH31QCDrJZF+LD64wjzDiJwxnWMlW/8sD3mj7OawdVml1wMAbWDXmzGzBPOlQh1N308WFidGBBidb8ci/KuQQ/J5aGITU5toD77intTgbnkl1NY/EWjmdFut5l5ybrcHjNfbLKU9OPOBOVEJuDQefbFr4qxg30xLzb0VeV9RKFive9eL3S169TAAfNsDjoT4oM2q3+pa8bQ+VcDcAYTfYxuxlKbAswD1L9mOCo+GJk5yNf83r6U69N7SrntZpg0hdu7g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(71200400001)(38100700002)(4326008)(6512007)(8676002)(6506007)(6486002)(8936002)(122000001)(54906003)(86362001)(83380400001)(6916009)(2906002)(99936003)(5660300002)(2616005)(478600001)(66476007)(33656002)(26005)(66946007)(66446008)(64756008)(316002)(66556008)(186003)(76116006)(75432002)(66616009)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /OCWC9LXjxGM5dPFXvsxb+WrARVay3srE9rQSSJjCCZjnkVZt05xWoC1KbFtV9TFE1ulHT4jpVbxgPFJOOgwerS/zAIwZeU3Zs31s8TWV7KKUtM2YpGVWwAZD2jCxZ3bzYerqAeb4fX6xlPVo27SKmkS3pggIZcK5MBGV+mDV78NmD17CtSHQPACCqFb4Zht7Sp3NQDQIGcCE+V3+musV5zG2z5pSzbSi6ldnEzoe1PR4cmstbgVvxC4OSK+WzlFRoksNyMMZVXVu6zRtlDSfXkjqXrRtC9XOkffWt99B5ZJvhW+BkBoqA6dzK8iRpPWOxxtP5rxBZCZnH2ejFhqt1uhaIJyn2knzfpx6vrgAZvSVqVWILd0Ke9ffgJW+Tu3bA1OedX0pP+O2CvAyiZMgKs2WCVG/lpz1gYZ1iQ/ko0VRQvPfbcnAI1B143JUDgH6Bd2ruPo+Lj7B55e5rw+TegXYzrbZt1aERHntwvOoOz2hdvHUKhOLJtQNP6xirXfflOPhBZtMa5qrr6CyjBcPtenKFQxe79gJ8lwAeQv/7mFJyFtGns/bMklVF9aB8UgWtQxDNcUi60fzZVHz/N6K4C3NNiVn6YFYJiTSwsYH2ot1xjxssox4uvhyngF8L6MytncQut0TQ94vxM8kYijYULJ0lVgZbkaJf/vQyJif/vEUmIZ6siIcdpwOOYhr2UQslMpf8cJkLgx036zu+OoVQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3706798019_329015571" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN5P110MB0560.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 11e0a032-6d22-4dc4-895b-08d931dc3af4 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 22:07:00.0156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0528 X-OriginatorOrg: ll.mit.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-17_16:2021-06-15, 2021-06-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=897 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2103310000 definitions=main-2106170134 Archived-At: Subject: Re: [saag] [lamps] META Re: PKIX and related RFCs - definition of Key Packages X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 22:08:17 -0000 --B_3706798019_329015571 Content-type: multipart/alternative; boundary="B_3706798019_1970739255" --B_3706798019_1970739255 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Thank you, and I concur. -- Regards, Uri There are two ways to design a system. One is to make is so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. - C. A. R. Hoare From: Spasm on behalf of Phillip Hallam-Baker Date: Thursday, June 17, 2021 at 17:20 Cc: "spasm@ietf.org" , "saag@ietf.org" Subject: [lamps] META Re: [saag] PKIX and related RFCs - definition of Key Packages I agree with much of Uri's frustration here. My concern is the meta level. If LAMPS is going to ever close, we have to make sure we are not going to need something similar in future. Which means that we need to define what is required to specify a cryptographic algorithm so it is available for use with IETF protocols. Note that adding an algorithm to a registry does not mean it is approved for use by a particular protocol. CMS serves a much wider audience than S/MIME. PKIX, a wider audience than either the WebPKI or PKI in general. Same for JOSE, XML Signature and Encryption, etc. etc. So I conclude that one of the exit criteria for LAMPS should be a document describing the list of things that need to be specified so that an algorithm can be used in various specific IETF protocols and conversely, what applications using the IETF maintained IANA registries can expect. I do not want to get into discussions of why the decisions of some working group ten years ago on algorithm requirements should bind some other group doing something different today. HTTP is not based on MIME but it uses the same IANA registry. That is the correct approach in my view. Going forward, I see no reason why it should be necessary to specify separate identifiers for the use of a particular algorithm in every different application protocol. The ASN.1 world is going to need OIDs for quite some time and the JOSE world is going to be needing text based labels. The XML world consumes URIs but there is no reason we couldn't specify a URN prefix to the JOSE labels and use that to avoid further maintenance issues. TLS and IPSEC both operate at a layer that is sufficiently deep that we should just let them do their own thing. And PEM probably isn't much of a concern going forward. --B_3706798019_1970739255 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Thank you, and I concur.

 

--

Regards,

Uri

 

There are= two ways to design a system. One is to make is so simple there are obviousl= y no deficiencies.

The ot= her is to make it so complex there are no obvious deficiencies.

      &= nbsp;             &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;           -  C= . A. R. Hoare

 

 

From: Spasm <spasm-bounces@ietf.org> on b= ehalf of Phillip Hallam-Baker <phill@hallambaker.com>
Date: = Thursday, June 17, 2021 at 17:20
Cc: "spasm@ietf.org" &l= t;spasm@ietf.org>, "saag@ietf.org" <saag@ietf.org>
= Subject: [lamps] META Re: [saag] PKIX and related RFCs - definition of K= ey Packages

 

I agree with much of Uri's f= rustration here. My concern is the meta level. If LAMPS is going to ever clo= se, we have to make sure we are not going to need something similar in futur= e. Which means that we need to define what is required to specify a cryptogr= aphic algorithm so it is available for use with IETF protocols.

 

Note that adding an= algorithm to a registry does not mean it is approved for use by a particula= r protocol. 

 

CMS serves a much wider audience than S/MIME. PKIX, a wider audie= nce than either the WebPKI or PKI in general. Same for JOSE, XML Signature a= nd Encryption, etc. etc.

 

So I conclude that one of the exit criteria for LAMPS= should be a document describing the list of things that need to be spe= cified so that an algorithm can be used in various specific IETF protocols a= nd conversely, what applications using the IETF maintained IANA registries c= an expect.

 

=

I do not want to get into discussions of why the decisions of some worki= ng group ten years ago on algorithm requirements should bind some other= group doing something different today. HTTP is not based on MIME but it use= s the same IANA registry. That is the correct approach in my view.

 

Going forward, I= see no reason why it should be necessary to specify separate identifiers fo= r the use of a particular algorithm in every different application protocol.= The ASN.1 world is going to need OIDs for quite some time and the JOSE worl= d is going to be needing text based labels. The XML world consumes URIs but = there is no reason we couldn't specify a URN prefix to the JOSE labels and u= se that to avoid further maintenance issues.

=  

TLS and IPSEC both operate at a layer = that is sufficiently deep that we should just let them do their own thi= ng. And PEM probably isn't much of a concern going forward. =

 

--B_3706798019_1970739255-- --B_3706798019_329015571 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCv9ObhNOsIIqZEVm02QDXxOpoFljLw+RGRAFnH WZzVczAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2MTcy MjA2NTlaMA0GCSqGSIb3DQEBAQUABIIBABiLEEx8Vp9fpUtK7UYcq5iu0os4a4qxgotVwi6n 0Lmp+awPkfvW/NrMaxIuHUXPWT8W5nVm1gE2k//UVjmU6fhnbiMD9E80Z2c+jIpqrcH9wwYk Zcitt2CuyCkjJexKaknGbz2B0bKTS2IgkUjrWVPrkCtidBYl9lkO/ywdkiIKlcO0idPzFL6q lIu1SmssQbALpD8Ij0WV8muS2Pw4X7NyUC3eaJIwbKml4nQ3dyFjGBYv4WDDa1/LtEBDf4n7 UFHJqpyc06sD24bnDbtJZ2gpRgBEEqboM/zyz8MoHRsHHac7gWvbyYiykMDrKKU0p41Fzn0R 6RldkBvGBDXm9K4= --B_3706798019_329015571-- From nobody Sun Jun 20 01:26:07 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D53A216E for ; Sun, 20 Jun 2021 01:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org 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 MjzYtRQUiNTV for ; Sun, 20 Jun 2021 01:25:58 -0700 (PDT) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0DB93A2168 for ; Sun, 20 Jun 2021 01:25:57 -0700 (PDT) Received: from Ophanim (bb220-255-247-16.singnet.com.sg [220.255.247.16]) by gondrom.org (Postfix) with ESMTPSA id D184172D1B; Sun, 20 Jun 2021 10:25:52 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=F0Rkari+5n06sUwlbQJ0Xu7nq4j8gdRkwKBQRM69ItkC1E/mpIT/c4QytuQo5t2dHNNKWfL9jSG1kTB3bHrfvZHJGBSBDgU6+bVqWB+ymeupZ0ekbaoGTK+6E8dLQ3bppdVVQJVuht7OPjorns+KELHsvr4WPKbqGAw9CZzWhdw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; From: To: "'Sean Turner'" , "'Roman Danyliw'" Cc: References: <12861641c9f345868f3201bfac6c3db9@cert.org> <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> In-Reply-To: <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> Date: Sun, 20 Jun 2021 16:25:50 +0800 Message-ID: <023101d765ad$e27e6200$a77b2600$@gondrom.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGtFA+ylbHpE2zWGFWggV7EKTiuOgHozLNuq2HrwuA= Content-Language: en-us Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 08:26:03 -0000 I took a review/look at this update as well. It has been a while since I last worked on ERS, so am a bit rusty... But reviewed and no problems as far as I can tell. Best regards, Tobias -----Original Message----- From: saag On Behalf Of Sean Turner Sent: Wednesday, June 9, 2021 11:04 PM To: Roman Danyliw Cc: saag@ietf.org Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules Roman, I have but one point to raise and then some cosmetic nits (cosmetic because compilers ignore whitespace). 0) Point to Raise: re: AllWantBacks. I am not entirely sure whether what is there for swb-ers-all WANT-BACK merely defines the new value or whether it also adds it to the list of available AllWantBacks. AllWantBacks is imported from RFC 5912: AllWantBacks WANT-BACK ::= { WantBackSet | ACertWantBackSet | AnyWantBackSet, ... } To add swb-ers-all to the list, I wonder whether merely defining it is enough. Is there something more that needs to be done to get it into the list as the fourth option? 1) Cosmetic Nits: Header: s/New ASN.1 Modules for the Evidence Recor /New ASN.1 Modules for the Evidence Record s2 (remove space, add space): s/{ v1(1) } ,/{ v1(1) }, s/AttributeSet{{ERSAttrSet}}/AttributeSet {{ERSAttrSet}} s3: Since the ExpandedWantBacks are All, New, and ERS might consider reorganizing them in the ASN to match that pattern. s (fix indention of evidence record)/ EvidenceRecordWantBack ::= SEQUENCE { targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), evidenceRecord EvidenceRecord OPTIONAL } / EvidenceRecordWantBack ::= SEQUENCE { targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), evidenceRecord EvidenceRecord OPTIONAL } s/{id-swb 16 }/{ id-swb 16 } s/{id-swb 17 }/{ id-swb 17 } s/{id-swb 18 }/{ id-swb 18 } s/{id-swb 19 }/{ id-swb 19 } s/{id-swb 20 }/{ id-swb 20 } > On May 14, 2021, at 16:45, Roman Danyliw wrote: > > Hi! > > Per the community interest and dispatch result at IETF 110 [1], I am AD sponsoring draft-housley-ers-asn1-modules [2]. > > I welcome early feedback or reviews on this document. > > Regards, > Roman > > [1] https://datatracker.ietf.org/doc/minutes-110-secdispatch/ > [2] https://datatracker.ietf.org/doc/draft-housley-ers-asn1-modules/ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Sun Jun 20 08:40:27 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6063E3A1A78 for ; Sun, 20 Jun 2021 08:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wn42TlmOfkcH for ; Sun, 20 Jun 2021 08:40:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B093A1A77 for ; Sun, 20 Jun 2021 08:40:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B7634300BEC for ; Sun, 20 Jun 2021 11:40:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id euatJ6ne3pFk for ; Sun, 20 Jun 2021 11:40:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 1E63D300B2C; Sun, 20 Jun 2021 11:40:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <023101d765ad$e27e6200$a77b2600$@gondrom.org> Date: Sun, 20 Jun 2021 11:40:12 -0400 Cc: "Roman D. Danyliw" , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: References: <12861641c9f345868f3201bfac6c3db9@cert.org> <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> <023101d765ad$e27e6200$a77b2600$@gondrom.org> To: Tobias Gondrom , Sean Turner X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 15:40:26 -0000 Thanks to Sean and Tobias for their reviews. As discussed by Carl in a previous response, item (0) in Sean's review = is not a problem. No change there. In the -02 version of the document, all but one of the rest were = addressed. Sean said: > Since the ExpandedWantBacks are All, New, and ERS might consider > reorganizing them in the ASN to match that pattern. The AllWantBacks is imported, so it necessarily comes at the top. Then, = NewWantBacks and ERSWantBacks are in the order listed. If a change is = needed, I'm not seeing it. Russ > On Jun 20, 2021, at 4:25 AM, = wrote: >=20 > I took a review/look at this update as well.=20 > It has been a while since I last worked on ERS, so am a bit rusty... > But reviewed and no problems as far as I can tell.=20 >=20 > Best regards, Tobias >=20 >=20 > -----Original Message----- > From: saag On Behalf Of Sean Turner > Sent: Wednesday, June 9, 2021 11:04 PM > To: Roman Danyliw > Cc: saag@ietf.org > Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules >=20 > Roman, >=20 > I have but one point to raise and then some cosmetic nits (cosmetic = because > compilers ignore whitespace). >=20 > 0) Point to Raise: >=20 > re: AllWantBacks. I am not entirely sure whether what is there for > swb-ers-all WANT-BACK merely defines the new value or whether it also = adds > it to the list of available AllWantBacks. AllWantBacks is imported = from RFC > 5912: >=20 > AllWantBacks WANT-BACK ::=3D { > WantBackSet | ACertWantBackSet | AnyWantBackSet, ... > } >=20 > To add swb-ers-all to the list, I wonder whether merely defining it is > enough. Is there something more that needs to be done to get it into = the > list as the fourth option? >=20 > 1) Cosmetic Nits: >=20 > Header: >=20 > s/New ASN.1 Modules for the Evidence Recor /New ASN.1 Modules for the > Evidence Record >=20 > s2 (remove space, add space): >=20 > s/{ v1(1) } ,/{ v1(1) }, > s/AttributeSet{{ERSAttrSet}}/AttributeSet {{ERSAttrSet}} >=20 > s3: >=20 > Since the ExpandedWantBacks are All, New, and ERS might consider > reorganizing them in the ASN to match that pattern. >=20 > s (fix indention of evidence record)/ > EvidenceRecordWantBack ::=3D SEQUENCE { > targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), > evidenceRecord EvidenceRecord OPTIONAL } / EvidenceRecordWantBack = ::=3D > SEQUENCE { > targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), > evidenceRecord EvidenceRecord OPTIONAL } >=20 > s/{id-swb 16 }/{ id-swb 16 } > s/{id-swb 17 }/{ id-swb 17 } > s/{id-swb 18 }/{ id-swb 18 } > s/{id-swb 19 }/{ id-swb 19 } > s/{id-swb 20 }/{ id-swb 20 } >=20 >> On May 14, 2021, at 16:45, Roman Danyliw wrote: >>=20 >> Hi! >>=20 >> Per the community interest and dispatch result at IETF 110 [1], I am = AD > sponsoring draft-housley-ers-asn1-modules [2]. >>=20 >> I welcome early feedback or reviews on this document. >>=20 >> Regards, >> Roman >>=20 >> [1] https://datatracker.ietf.org/doc/minutes-110-secdispatch/ >> [2] https://datatracker.ietf.org/doc/draft-housley-ers-asn1-modules/ >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Jun 21 07:54:47 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328E23A092E for ; Mon, 21 Jun 2021 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 PTertZe0agpl for ; Mon, 21 Jun 2021 07:54:41 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 297FF3A0927 for ; Mon, 21 Jun 2021 07:54:41 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id d9so4145708qtx.8 for ; Mon, 21 Jun 2021 07:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8285NRWScJ0wi6IBfv76utRPYulq+jKAsVZDI7tet1I=; b=UJmm/FOsAizgO08gKCnh5lmtIIbVCRCesIuQvUluber8qPmKOeiexTOT+UZg+FRYPF XnU5uE7xFDVRz+tbSkNnhyU8lIeJokyzbfpWDPAiKpxoZP0EUJppjwl7ZPhdcZwuo60E jfMrAbxtC2D7J/u4gWTEvK9ilmnvHRdHpHpWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8285NRWScJ0wi6IBfv76utRPYulq+jKAsVZDI7tet1I=; b=Hn4tIZPWa+fokhzRAe0Af58JXaX7wy7zjGOFSG2lcSaN3W4o6QPRSUcxX4e/GHlqjc Ii9Emd6NH00Pg8coozfypAIhHnZeLEtVto+KMPBh6wC5FkjFD8aFKNrqHpGdurg8P0lz 1H7oeoXjPrVhx+N7Is///gvHXfpwHvNuflH4YC+8Lb7YEVZ2+7jZSoW3nkScpSqcl6hO Q9yk2SrlIJlp5/eVuEuYll4yFlXACsMy53CvDH7k+dWC5SMpLwEUXiB06guTTnYiw0zH /KwMjQIg7chlbjqoCS+G/Saaq+C8aEu9l6f9Qdl3ipbWvPb1eBEPzIKdBWebKPTfStXL 8RXA== X-Gm-Message-State: AOAM532XBQBVmnfx9MIW1FYpXKo2Xx85zaxdQpzADHfhqHtJPopk8nPD ZrYcu0Nhn5aQzFBfuScPVWbF3A== X-Google-Smtp-Source: ABdhPJxbMq7PUjO+eW43+v8tM2v32VA4whguDbm1HE+dvzXccXIEfwcsecpacIc23hdgFN4xccWw9A== X-Received: by 2002:ac8:7357:: with SMTP id q23mr24516635qtp.226.1624287279564; Mon, 21 Jun 2021 07:54:39 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id y3sm10035059qkf.2.2021.06.21.07.54.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Jun 2021 07:54:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Sean Turner In-Reply-To: Date: Mon, 21 Jun 2021 10:54:38 -0400 Cc: Tobias Gondrom , Roman Danyliw , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: References: <12861641c9f345868f3201bfac6c3db9@cert.org> <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> <023101d765ad$e27e6200$a77b2600$@gondrom.org> To: Russ Housley X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 14:54:46 -0000 > On Jun 20, 2021, at 11:40, Russ Housley wrote: >=20 > Thanks to Sean and Tobias for their reviews. >=20 > As discussed by Carl in a previous response, item (0) in Sean's review = is not a problem. No change there. >=20 > In the -02 version of the document, all but one of the rest were = addressed. Sean said: >=20 >> Since the ExpandedWantBacks are All, New, and ERS might consider >> reorganizing them in the ASN to match that pattern. >=20 > The AllWantBacks is imported, so it necessarily comes at the top. = Then, NewWantBacks and ERSWantBacks are in the order listed. If a = change is needed, I'm not seeing it. Yep I misread that. They are in the order that they appear in = ERSWantBacks. > Russ >=20 >=20 >> On Jun 20, 2021, at 4:25 AM, = wrote: >>=20 >> I took a review/look at this update as well.=20 >> It has been a while since I last worked on ERS, so am a bit rusty... >> But reviewed and no problems as far as I can tell.=20 >>=20 >> Best regards, Tobias >>=20 >>=20 >> -----Original Message----- >> From: saag On Behalf Of Sean Turner >> Sent: Wednesday, June 9, 2021 11:04 PM >> To: Roman Danyliw >> Cc: saag@ietf.org >> Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules >>=20 >> Roman, >>=20 >> I have but one point to raise and then some cosmetic nits (cosmetic = because >> compilers ignore whitespace). >>=20 >> 0) Point to Raise: >>=20 >> re: AllWantBacks. I am not entirely sure whether what is there for >> swb-ers-all WANT-BACK merely defines the new value or whether it also = adds >> it to the list of available AllWantBacks. AllWantBacks is imported = from RFC >> 5912: >>=20 >> AllWantBacks WANT-BACK ::=3D { >> WantBackSet | ACertWantBackSet | AnyWantBackSet, ... >> } >>=20 >> To add swb-ers-all to the list, I wonder whether merely defining it = is >> enough. Is there something more that needs to be done to get it into = the >> list as the fourth option? >>=20 >> 1) Cosmetic Nits: >>=20 >> Header: >>=20 >> s/New ASN.1 Modules for the Evidence Recor /New ASN.1 Modules for the >> Evidence Record >>=20 >> s2 (remove space, add space): >>=20 >> s/{ v1(1) } ,/{ v1(1) }, >> s/AttributeSet{{ERSAttrSet}}/AttributeSet {{ERSAttrSet}} >>=20 >> s3: >>=20 >> Since the ExpandedWantBacks are All, New, and ERS might consider >> reorganizing them in the ASN to match that pattern. >>=20 >> s (fix indention of evidence record)/ >> EvidenceRecordWantBack ::=3D SEQUENCE { >> targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), >> evidenceRecord EvidenceRecord OPTIONAL } / EvidenceRecordWantBack = ::=3D >> SEQUENCE { >> targetWantBack WANT-BACK.&id ({ExpandedWantBacks}), >> evidenceRecord EvidenceRecord OPTIONAL } >>=20 >> s/{id-swb 16 }/{ id-swb 16 } >> s/{id-swb 17 }/{ id-swb 17 } >> s/{id-swb 18 }/{ id-swb 18 } >> s/{id-swb 19 }/{ id-swb 19 } >> s/{id-swb 20 }/{ id-swb 20 } >>=20 >>> On May 14, 2021, at 16:45, Roman Danyliw wrote: >>>=20 >>> Hi! >>>=20 >>> Per the community interest and dispatch result at IETF 110 [1], I am = AD >> sponsoring draft-housley-ers-asn1-modules [2]. >>>=20 >>> I welcome early feedback or reviews on this document. >>>=20 >>> Regards, >>> Roman >>>=20 >>> [1] https://datatracker.ietf.org/doc/minutes-110-secdispatch/ >>> [2] https://datatracker.ietf.org/doc/draft-housley-ers-asn1-modules/ >>>=20 >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 From nobody Mon Jun 21 08:01:56 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8279F3A09B0 for ; Mon, 21 Jun 2021 08:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 XmSYZiQWHz_1 for ; Mon, 21 Jun 2021 08:01:50 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 075EC3A0991 for ; Mon, 21 Jun 2021 08:01:49 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id j184so31236369qkd.6 for ; Mon, 21 Jun 2021 08:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=emonvtt0V6iDOvDpKvsBUazF8XlPDAQRwpv9C2MK9Ao=; b=SvFVH4a6rDVp3sIFaY5duObTCcJk4cmdYk8geFJ9q4pShE6MpBKbPXl1Bf/vAXaCLL O7IWC6i0fnIB2a6dWq0yjngzW+bVSgUVreD4tmUYpQrh8+4TOJ59n3RaugUNlbkIFDYO yJCAooCSDEyc6mYF3tYPLbrmliBBaLNAMawnM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=emonvtt0V6iDOvDpKvsBUazF8XlPDAQRwpv9C2MK9Ao=; b=Pmg9Q/cX+YZ0vnUo6YAstn+MHR3vDSaD1FDGqJC71Q1/2yxukyPJeXYmL3LU8JD/gy oqZ8hmt4+lzdAASAlzfbMK/6cYXG0iJan0CmGQZHsQ251zdHl20O0BiFERj2De7voc+H a8klNMxcoMVw8rsOLTgpXcUCpVXwq4KV+zwemAkC3n7NFbAME56y3Cc7qh6Syvm/PTpN KjdSZXygdDoY8AyJyMSrNew30TyaUP1BH5wJkEkEQYJAAg3pwln+mf52lysOE/tqIdfm 201rHC44LdCzh+74qCMzmyzMW4pAkQNUQ3Ot4PE1DlIr8gbrKzHdEU/kZfgBo/RT1LFE l/dQ== X-Gm-Message-State: AOAM531uclIgGouQfx4n9nwtIQD00PrAKDiMa2NfUepfEw5jNgVFFL5C TakVaHYZ3X8onshpMYbGicK7iw== X-Google-Smtp-Source: ABdhPJyWfxYNf3/DBvliFbbGWM9Jrzm13XlPyrUfesvSqvFTDNFgTc2sb6qIIhCiKTIBHPnRBNn0OQ== X-Received: by 2002:a05:620a:304:: with SMTP id s4mr23084904qkm.143.1624287708057; Mon, 21 Jun 2021 08:01:48 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id 11sm3421751qkv.53.2021.06.21.08.01.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Jun 2021 08:01:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Sean Turner In-Reply-To: <418C66BE-E450-4081-89BD-B04A158D33FA@redhoundsoftware.com> Date: Mon, 21 Jun 2021 11:01:46 -0400 Cc: Roman Danyliw , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <118D63AB-13DB-4272-BC38-E04B279CD00B@sn3rd.com> References: <12861641c9f345868f3201bfac6c3db9@cert.org> <2474C9E1-2860-4648-BD94-1A084CFA21A4@sn3rd.com> <418C66BE-E450-4081-89BD-B04A158D33FA@redhoundsoftware.com> To: Carl Wallace X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [saag] AD Sponsorship of draft-housley-ers-asn1-modules X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 15:01:55 -0000 > On Jun 10, 2021, at 13:31, Carl Wallace = wrote: >=20 > Inline... >=20 > =EF=BB=BFOn 6/9/21, 11:03 AM, "saag on behalf of Sean Turner" = wrote: >=20 > Roman, >=20 > I have but one point to raise and then some cosmetic nits (cosmetic = because compilers ignore whitespace). >=20 > 0) Point to Raise: >=20 > re: AllWantBacks. I am not entirely sure whether what is there for = swb-ers-all WANT-BACK merely defines the new value or whether it also = adds it to the list of available AllWantBacks. AllWantBacks is imported = from RFC 5912: >=20 > AllWantBacks WANT-BACK ::=3D { > WantBackSet | ACertWantBackSet | AnyWantBackSet, ... > } >=20 > To add swb-ers-all to the list, I wonder whether merely defining it = is enough. Is there something more that needs to be done to get it into = the list as the fourth option? >=20 > [CW] The swb-ers-all does not impact AllWantBacks. It was simply a = shorthand means of saying "I want an EvidenceRecord for everything in = replyWantBacks". See the last paragraph of section 3 in RFC5276. The = ExpandedWantBacks in this draft is a superset of AllWantBacks. Unless I = am missing something, I do not see a concern.=20 >=20 > Ah! I see it now - you=E2=80=99re not expanding AllWantBacks. Not sure = why I got it in my head that you were trying to expand AllWantsBacks. = lgtm now. spt= From nobody Wed Jun 23 13:35:36 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C383A3FA1 for ; Wed, 23 Jun 2021 13:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Dsy6TwHqw3kB for ; Wed, 23 Jun 2021 13:35:30 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00060.outbound.protection.outlook.com [40.107.0.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E37E3A3FA4 for ; Wed, 23 Jun 2021 13:35:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NcWZIDPQyl852c/wLWp1/OmQOdB1Y0h9qVKN2P+q9oQL2w92KBUWJYdZgmsqKx2h4t42LblF4ztvEwlumMu2YMB9M+CkjttTy4W5czqNkgAoXQHKVKQg8VR2X4N5whjLYIv3cpJoUuoxs5sWTOqXLxqO08DKTrpZLGi3/XKeaMbYztbs81DlMMYmUzwUeOa8se8chkIUOWjqMhkQLEyPWETIr52QBGo87Lu/sCk8Bjykq6qwnbfQ7gdjeONFZI09jQgZoNxbXEgar36rSv0oNQ24slXNwQy8/jZ7/ZSoGW/e4h2DCSeC8Hz10NADo80ydiPhqDJJTGolnBHX9URDpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XseXl7DqX3ro13y+KcbdJGeRy3VhM2yluPVjoEthU/g=; b=Wj0siXTTSJKBrUy4OcOtgeu1g9upXuX8QzS160ug9VIzH5axhl4pdOjqN/vNrMFbqij1RWGqJWUP029cpM9MsOUht2pEW8Bxe8bT0a73/KuWXRrAza+zgCeT3ASTVgR6zJr1uE1aGcZkrM8afPw+86VLFR1TipIXB6Ht/Ol7ObVh7Vibjx7UKfvEvnSbVFJY+AmWRFktTGyRMb6w37wu523G+0qgXFmY2MObp9knrC3DxmSWyMyVz9NLUsU5IOX1/X/503TVwd6EzHl9CQ28HBd6oawGJSrMfk9F39WiI8wkDgspSKm3QYnpDpFxAFPIDVSzKT33NT/Kc3NZv2yRNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XseXl7DqX3ro13y+KcbdJGeRy3VhM2yluPVjoEthU/g=; b=AaqUv69H3D29abZl1iC0SMrjSGOcBCcgyd78k5oQWXRAGxESh4ggJ9Ee5GOGEmQKgdC7xa51kfqru7G02hw1ECJqlqLnatGzcSOhe+aWJxaylEwAwvM3Y6yPHU+QCser7JDIwJS0txHCoDWXPZAcL4/dcCXiwandQNwpEEHIWT8= Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR07MB4362.eurprd07.prod.outlook.com (2603:10a6:7:9a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.16; Wed, 23 Jun 2021 20:35:24 +0000 Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4264.019; Wed, 23 Jun 2021 20:35:24 +0000 From: John Mattsson To: saag Thread-Topic: =?Windows-1252?Q?Public_key_parameters_in_the_signature_algorithm_=97that?= =?Windows-1252?Q?_is_the_question?= Thread-Index: AQHXaG6TVNtv3OZw7Ua53LZ9cSb8aA== Date: Wed, 23 Jun 2021 20:35:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 63b3c9d1-4ece-40a6-46ef-08d936866d99 x-ms-traffictypediagnostic: HE1PR07MB4362: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: psSmuk1e/omrHFNyYb/1SZ25vPxnIm9N2BwYbsXd2ck5V0/oooxO7D/Mi3yE/oILb3SftPy+zTlSOi1CMz0Hw+YdKdXacSSK5Llupf2VLxQl5NcJnf6Zrs26QJs5Rkr+TIGy8ihrsBlIZlXAKKGH6GvMWYjNxR+Fx2O8Se8s+AnbBzD5RyGgy3/5FsJTfoV6JSTOj2HAWYqszjn6quKVjKbnOpL5aNWcDU2d5zd5csfCOb9wnAgh8qoVLh4D4C4zOGQTpcpZ+CExziPZ9tK6xqJzh2iQdLbJZ5RioVLOgmlCiGxRsP+KNT31KqeY23LMc+rMB02XEmACN6iOn9YZj/QBL9nXdanK/v/lS6S7F8D9owtmZ9w0CtIGwD8BCTy7/ziXn948eamdFFRosUXQYzRSSFDJr0gKqIDZmCbqXcjI5Sskt0QMC+L61+ueHzAmOYADOLh5tJHBkIIxXyXEymnrOFxvLWPEcOGrmW/PcS2bTfalT44rwRAvBNRc3eJi+1FCE93wFuf9VJKuUUNzz7O15STthM8Jsp4xkNdsTLebue4R75mnoDY9flaEgC8QWICtVpaq0XIYqdmWYxN8dxtr3+fpTkmCqNqoHLL5T1JoFRQNfsWqyWd8EXbnizHpTLfNLbv9lvY18FfQrG47mg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(346002)(136003)(376002)(39860400002)(2906002)(33656002)(8936002)(186003)(55016002)(66946007)(76116006)(6506007)(316002)(7696005)(71200400001)(64756008)(66476007)(122000001)(38100700002)(26005)(44832011)(9686003)(52536014)(66446008)(86362001)(66556008)(6916009)(478600001)(83380400001)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ZxFo5MrxfpLEES8mckA71/D1UnXost/nxPCGkDcgezMpe3oy9jbNcyoM?= =?Windows-1252?Q?gCyVHIG+Ld6RQatJdcV3k/+Oj8OPJRkpvA6h8aO7pNVgQHu2cU74qIt5?= =?Windows-1252?Q?QNhuFG+yzvg/Pb5IyZYAkr6VK4NAODXS1zzBT32lGAOlaa7B1+hgxVxt?= =?Windows-1252?Q?gr7kYcZ9TVs6fJhO+M/vF32+GHNKsOEPNWZ1umr4uxmWkzWxC7S2Nh+D?= =?Windows-1252?Q?pm//Hcix5BstjnP9YYeWIjULYHaviM9MXRp0/m/5Nqrrab3jI3ORs6Ha?= =?Windows-1252?Q?0cn47Ho8nwE6l8fTIrt5hX8m5QFn6XsIYJfpgbvkmjslNF+3VKR4JBHb?= =?Windows-1252?Q?ykJuw9wZHoDc3TT6Sy4/r/Ta/guS19Lob8R2Qf2ejow9HISAWVWBVzPh?= =?Windows-1252?Q?Tn8oc+dLDVcIQ54mbpQGYQ+21FGpGnXJJT5Io/F6m8Aw3VNtGh1B7Qm0?= =?Windows-1252?Q?s+KHE8W7ihniaPxco0t1DttEhsKcqUMn9bSQjU/BfjZxiR0GvWXb6pZD?= =?Windows-1252?Q?SPCQp+Cc+/F/iBec1CHJwgc62nJXNeBVnGNdp8hz1ILHc3Js4rUmfYBk?= =?Windows-1252?Q?IHRFokDUK9kMFYfKpt5cpwmNDD807qsdGExQLSE4kTnHGuYfwKGInMVn?= =?Windows-1252?Q?A5YzV+4ZWpAl6QJBpmSkj1c2tSOmZFMSj/gsIdVNpjGxWIRDRIxMjy0R?= =?Windows-1252?Q?qsGXDdrE1JxSyzU+mFHiEZMQqr5I+qCBIwyROKicy6cpt+9htUuMTAmB?= =?Windows-1252?Q?nCu8mfkkqppVMY3uQWRRaTtojhErcfBmZ5ktGkPoFz023ILPNgqNPvzI?= =?Windows-1252?Q?z0wPJAaBiySAdZTvBwdkXENmlFFlVU2Jjd948qS53LOweBzFeK9pt1jj?= =?Windows-1252?Q?jUaFBSbShqoxQWXbRtzpGj7arpgRN+uQhpITUhjs27E4S5kclCpqCH+/?= =?Windows-1252?Q?Nu0deGOUlRYMhIOq67e5P2lung+5HoDRsoWh87/NANN2Yogzlzb4uHZq?= =?Windows-1252?Q?7bRXzQPHnFXF1XP7kPVawkX+mMEDRrbp3A7yaDy6zQkEptwGxRO2pxD3?= =?Windows-1252?Q?aGhsVYYbA2C/87G9yQKpSWm/BAhu/3Zrne3NT4MvKWRB9CqKA2NzVMCt?= =?Windows-1252?Q?7dQeTUAqo9mKB766dxINaaSMCKcA7FRCAxaxXfhkOy8kyeLdHb8XRJNg?= =?Windows-1252?Q?ESPdfN2PV/G9rydDdaBY33+G7YhsjSscQ+uPKy8YICWPxUsFbMqvNviI?= =?Windows-1252?Q?fQ5cShcHE4JlS67QJbbFjBzrTFDXv989QcsWgWfpv1lsIJk8TGwjNREH?= =?Windows-1252?Q?FKmD+MDIuAuW+IXIj7aOnrBeK+t81C9bWbrud888Z5Hpxi588FMUytzt?= =?Windows-1252?Q?FI80ktCUwd9aLeyLeI0RCgEaNfgFUM7bOp0j+4sSpeXOEu5AUxYMiNuk?= =?Windows-1252?Q?VCLLCwuQ0sG3bOhnxF4Z2w=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB30506C4D58CF5F9CF476CAD689089HE1PR0701MB3050_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63b3c9d1-4ece-40a6-46ef-08d936866d99 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2021 20:35:24.1185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MJmIDyjxQ3GvvH1p+CDoZU5ZB/5RmoOxi5uG8Fa4nXZ70VI5hZVHGc++JkdpTMDMknUejGqRr+ykgRShm12fA9QXiKqj5tiuZeqqrMOmcRo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4362 Archived-At: Subject: [saag] =?windows-1252?q?Public_key_parameters_in_the_signature_a?= =?windows-1252?q?lgorithm_=97that_is_the_question?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 20:35:35 -0000 --_000_HE1PR0701MB30506C4D58CF5F9CF476CAD689089HE1PR0701MB3050_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, There has been a lot of discussions in various groups recently on whether t= o have public key parameters also in the signature algorithm or not. There = are significant differences between IETF protocols like PKIX, JOSE, COSE, T= LS 1.2, TLS 1.3, and IKEv2. Many of the protocols are also internally incon= sistent. The inconsistency has led to a lot of confusion for developers and= people writing specifications. Looking at IETF protocols with signature algorithm registers: - PKIX/X.509 is consistent. There is no duplication of parameters between t= he public key algorithm and the signature algorithms. - TLS 1.2 is consistent. None of the signature algorithms include public ke= y parameters. - COSE is inconsistent. COSE largely following PKIX. The exception is the s= ignature algorithm ES256K that includes the public key parameter secp256k1. - JOSE is inconsistent. JOSE is mostly doing the opposite as COSE and inclu= des many public key parameters in the signature algorithms. Exceptions are = EdDSA that do not include the curve, and the RSA algorithms that do not inc= lude the key size. - IKEv2 is inconsistent. IKEv2 started its own registry where the ECDSA sig= nature algorithms is bound to a curve, but the RSA signature algorithm does= not include the key size. IKEv2 have since specified a way to use PKIX/X.5= 09 registries where signature algorithms do not include any public key para= meters. - TLS 1.3 is inconsistent. ECDSA, EdDSA, sm2sig_sm3, and gost include the c= urve, but eccsi_sha256, iso_ibs1, iso_ibs2, and iso_chinese_ibs. RSA does n= ot include the key length. - draft-ietf-httpbis-message-signatures is inconsistent. ECDSA includes cur= ve, but RSA does not include key length and JOSE EdDSA does not include cur= ve. I have seen at least the following arguments to include public key paramete= rs in the signature algorithm: 1. An implementation should know based on the signature algorithm that is s= upport calculating the signature. 2. The security level should follow from the signature algorithm 3. Avoid using the same public key with two different algorithms My observations and thoughts: - I think consistency is the most important property here. - The protocols except PKIX, COSE, and TLS 1.2 seems to try to achieve 1. b= ut fail as they are not consistent. - None of the protocols above seem to strive for 2. - Adding public key parameters to the signature algorithm does not seem to = achieve 3. A way to achieve 3. would e.g., be to add signature algorithm OI= Ds to the Extended Key Usage and only use algorithms specified there. Cheers, John --_000_HE1PR0701MB30506C4D58CF5F9CF476CAD689089HE1PR0701MB3050_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

There has been a lot of discuss= ions in various groups recently on whether to have public key parameters al= so in the signature algorithm or not. There are significant differences bet= ween IETF protocols like PKIX, JOSE, COSE, TLS 1.2, TLS 1.3, and IKEv2. Many of the protocols are also internal= ly inconsistent. The inconsistency has led to a lot of confusion for develo= pers and people writing specifications.

 

Looking at IETF protocols with = signature algorithm registers:

 

- PKIX/X.509 is consistent. The= re is no duplication of parameters between the public key algorithm and the= signature algorithms.

 

- TLS 1.2 is consistent. None o= f the signature algorithms include public key parameters.=

 

- COSE is inconsistent. COSE la= rgely following PKIX. The exception is the signature algorithm ES256K that = includes the public key parameter secp256k1.

 

- JOSE is inconsistent. JOSE is= mostly doing the opposite as COSE and includes many public key parameters = in the signature algorithms. Exceptions are EdDSA that do not include the c= urve, and the RSA algorithms that do not include the key size.

 

- IKEv2 is inconsistent. IKEv2 = started its own registry where the ECDSA signature algorithms is bound to a= curve, but the RSA signature algorithm does not include the key size. IKEv= 2 have since specified a way to use PKIX/X.509 registries where signature algorithms do not include any public= key parameters.

 

- TLS 1.3 is inconsistent. ECDS= A, EdDSA, sm2sig_sm3, and gost include the curve, but eccsi_sha256, iso_ibs= 1, iso_ibs2, and iso_chinese_ibs. RSA does not include the key length.

 

- draft-ietf-httpbis-message-si= gnatures is inconsistent. ECDSA includes curve, but RSA does not include ke= y length and JOSE EdDSA does not include curve.

 

I have seen at least the follow= ing arguments to include public key parameters in the signature algorithm:<= o:p>

1. An implementation should kno= w based on the signature algorithm that is support calculating the signatur= e.

2. The security level should fo= llow from the signature algorithm

3. Avoid using the same public = key with two different algorithms

 

My observations and thoughts:

- I think consistency is the mo= st important property here.

- The protocols except PKIX, CO= SE, and TLS 1.2 seems to try to achieve 1. but fail as they are not consist= ent.

- None of the protocols above s= eem to strive for 2.

- Adding public key parameters = to the signature algorithm does not seem to achieve 3. A way to achieve 3. = would e.g., be to add signature algorithm OIDs to the Extended Key Usage an= d only use algorithms specified there.

 

Cheers,

John

 

--_000_HE1PR0701MB30506C4D58CF5F9CF476CAD689089HE1PR0701MB3050_--