From nobody Mon Nov 20 09:20:39 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EEA12957F for ; Mon, 20 Nov 2017 09:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 XzyHuIOa0Umy for ; Mon, 20 Nov 2017 09:20:35 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id A90A5129C5D for ; Mon, 20 Nov 2017 09:20:34 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 52A683740FB2 for ; Mon, 20 Nov 2017 17:20:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bnhw_qX1wA5q for ; Mon, 20 Nov 2017 12:20:33 -0500 (EST) Received: from nuc.openca.org (207-38-147-98.s4930.c3-0.avec-ubr2.nyr-avec.ny.cable.rcncustomer.com [207.38.147.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DE5003740C38 for ; Mon, 20 Nov 2017 12:20:32 -0500 (EST) To: pkix@ietf.org From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Mon, 20 Nov 2017 12:20:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030200010506070209050201" Archived-At: Subject: [pkix] PKIX and Revocation - Time to move forward! X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 17:20:38 -0000 This is a cryptographically signed message in MIME format. --------------ms030200010506070209050201 Content-Type: multipart/alternative; boundary="------------D4F9F7D1EEFBEBCD2E5BEFB4" Content-Language: en-US This is a multi-part message in MIME format. --------------D4F9F7D1EEFBEBCD2E5BEFB4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, although it seems that in the SEC area there is little interest in=20 addressing the issue of revocation, we think it is still important to=20 address it. Unfortunately, since the PKIX WG was closed, this type of=20 work has no house and, as a consequence, there has been NO improvement=20 on PKIX in AGES! We are currently working on a couple of proposals that we are going to=20 deploy (independently from IETF's interest in it) in several industry=20 segments and related organizations. In particular, we have two different = proposals. The first is the OCSP over DNS that aims at providing an=20 additional transport protocol for OCSP responses (i.e., it is an=20 alternative to OCSP over HTTP and not, as some people wrongly focused=20 on, as a replacement of OCSP stapling). The draft is currently available = here: * https://datatracker.ietf.org/doc/draft-pala-odin/ For the second proposal, we are not ready to disclose it but it is=20 related to improve and simplify revocation information checking. In order to make a good case around the new design, I wanted to ask the=20 PKIX WG few questions that would help confirming or rejecting our=20 assumptions related to some PKIX ops (from a CA perspective). These are my questions: * *Does anyone remember why the use of non-sequential random serial number for certificates was introduced ?* Initially, I think, it was an attempt at masking the number of issued certificates from a CA. Then, there was some kind of argument about the "randomness" of data within certificates (that did not make sense to me, really, since the public key provides plenty of randomness) - maybe this was combined with the fear of having "weak" hash algorithms for signing certificates ? I.e., SHA-1 ? If that is correct, would the use of SHA2 family (or next gen ones) solve the issue and remove the alleged need for random serial numbers ? * *Why the OCSP protocol behavior was shifted from revocation checking to validity checking ?* When the OCSP protocol was first standardized, it was meant to provide revocation information (an alternative to CRLs) - in particular when no revocation information existed related to a requested serial number, the response would carry the "valid" response. Following some compromises of CAs, the CAB forum (???) decided to mandate for a different interpretation of the OCSP: instead of a revocation checking mechanism, they wanted to use it as a validation mechanism in the sense that "valid" responses were to be returned only for serial numbers of ISSUED certificates and not for serial numbers for which no revocation information existed (i.e., even if a certificate with the requested serial number was never issued). If I am not mistaken, this was an attempt at certificate transparency - for which now we have a whole set of (overly complicated, IMHO) infrastructure :-( If that is true, wouldn't be the original intended usage of OCSP be more appropriate today ? Since in the recent years we developed lots of experience when it comes=20 to what and how is actually used for revocation checking, I think we can = easily provide simpler designs with lower operational costs and,=20 consequently, better (more frequent) updates [*] for revocation=20 information that take all these considerations into account (in=20 particular, the requirements related to the 2nd question above have=20 pushed the costs of providing revocation information - probably an=20 not-intended consequence/side effect). Thanks everybody in advance for all your feedback/insights, and please=20 let me know if you are interested in collaborating and in which capacity.= Cheers, Max [*] Because of this shift in OCSP behavior, CAs now issue OCSP responses = that have validity of up to 7 days, which is definitely not what OCSP=20 was intended for (usually few minutes, hours or maybe one day max was=20 initially view --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------D4F9F7D1EEFBEBCD2E5BEFB4 Content-Type: multipart/related; boundary="------------429AF4C870FF4BB666952209" --------------429AF4C870FF4BB666952209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

although it seems that in the SEC area there is little interest in addressing the issue of revocation, we think it is still important to address it. Unfortunately, since the PKIX WG was closed, this type of work has no house and, as a consequence, there has been NO improvement on PKIX in AGES!

We are currently working on a couple of proposals that we are going to deploy (independently from IETF's interest in it) in several industry segments and related organizations. In particular, we have two different proposals. The first is the OCSP over DNS that aims at providing an additional transport protocol for OCSP responses (i.e., it is an alternative to OCSP over HTTP and not, as some people wrongly focused on, as a replacement of OCSP stapling). The draft is currently available here:

For the second proposal, we are not ready to disclose it but it is related to improve and simplify revocation information checking.

In order to make a good case around the new design, I wanted to ask the PKIX WG few questions that would help confirming or rejecting our assumptions related to some PKIX ops (from a CA perspective).

These are my questions:

  • Does anyone remember why the use of non-sequential random serial number for certificates was introduced ? Initially, I think, it was an attempt at masking the number of issued certificates from a CA. Then, there was some kind of argument about the "randomness" of data within certificates (that did not make sense to me, really, since the public key provides plenty of randomness) - maybe this was combined with the fear of having "weak" hash algorithms for signing certificates ? I.e., SHA-1 ? If that is correct, would the use of SHA2 family (or next gen ones) solve the issue and remove the alleged need for random serial numbers ?

  • Why the OCSP protocol behavior was shifted from revocation checking to validity checking ? When the OCSP protocol was first standardized, it was meant to provide revocation information (an alternative to CRLs) - in particular when no revocation information existed related to a requested serial number, the response would carry the "valid" response. Following some compromises of CAs, the CAB forum (???) decided to mandate for a different interpretation of the OCSP: instead of a revocation checking mechanism, they wanted to use it as a validation mechanism in the sense that "valid" responses were to be returned only for serial numbers of ISSUED certificates and not for serial numbers for which no revocation information existed (i.e., even if a certificate with the requested serial number was never issued). If I am not mistaken, this was an attempt at certificate transparency - for which now we have a whole set of (overly complicated, IMHO) infrastructure :-( If that is true, wouldn't be the original intended usage of OCSP be more appropriate today ?

Since in the recent years we developed lots of experience when it comes to what and how is actually used for revocation checking, I think we can easily provide simpler designs with lower operational costs and, consequently, better (more frequent) updates [*] for revocation information that take all these considerations into account (in particular, the requirements related to the 2nd question above have pushed the costs of providing revocation information - probably an not-intended consequence/side effect).

Thanks everybody in advance for all your feedback/insights, and please let me know if you are interested in collaborating and in which capacity.

Cheers,
Max

[*] Because of this shift in OCSP behavior, CAs now issue OCSP responses that have validity of up to 7 days, which is definitely not what OCSP was intended for (usually few minutes, hours or maybe one day max was initially view

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA

--------------429AF4C870FF4BB666952209 Content-Type: image/png; name="pnihaobajhigodgn.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="pnihaobajhigodgn.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------429AF4C870FF4BB666952209-- --------------D4F9F7D1EEFBEBCD2E5BEFB4-- --------------ms030200010506070209050201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MjAxNzIwMzFaMC8GCSqGSIb3DQEJBDEiBCBGdPBv30Iazqk0TJuyPv52YPB/6Rklkre8xT3r eJwBRzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAKIQbD9kK386u1k1 g1BF2eviVeiTAEPr8xAILyN7MPKtEb78A++9YU9VDv71wIjh5YJuTLsuGz6XK3Cvm1bLDil6 pk+3RqjuBLdqol+9n8sHyDjupzefIHWpbhOuzOL5h+Cnnb4Yn3o55m7qByqTDDJLkrbLo27R C+LSKeusvPOfLzdtRGGRdjNm4qH2d91YI7ui/X1fADkiVOb7sKtsuBljcE1p0S9rA8o0lbrk 8xHdW60ZEholzyNeFi5dFSJKMplZyPax3vTVjLSLrzTkJcRGkYyGhHvVTA9eyRNqoo163wS4 WwFZP3fKbfmCxE7piT/x+d5LheKXVlAXjO7uIGUAAAAAAAA= --------------ms030200010506070209050201-- From nobody Mon Nov 20 15:27:45 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977531200CF for ; Mon, 20 Nov 2017 15:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, 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 azaoa4abOGiq for ; Mon, 20 Nov 2017 15:27:41 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id DF0041200C1 for ; Mon, 20 Nov 2017 15:27:40 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id AFCC63740FB2; Mon, 20 Nov 2017 23:27:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W8imfV_s9Jvb; Mon, 20 Nov 2017 18:27:39 -0500 (EST) Received: from nuc.openca.org (207-38-147-98.s4930.c3-0.avec-ubr2.nyr-avec.ny.cable.rcncustomer.com [207.38.147.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 0636F3740C38; Mon, 20 Nov 2017 18:27:38 -0500 (EST) To: ryan@sleevi.com Cc: pkix@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <911de2ae-d8c3-c230-72c2-bcdaa2fedf43@openca.org> Date: Mon, 20 Nov 2017 18:27:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080204040108010903080603" Archived-At: Subject: Re: [pkix] PKIX and Revocation - Time to move forward! X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 23:27:43 -0000 This is a cryptographically signed message in MIME format. --------------ms080204040108010903080603 Content-Type: multipart/alternative; boundary="------------BE229C229DDD4A0BE6E17D9A" Content-Language: en-US This is a multi-part message in MIME format. --------------BE229C229DDD4A0BE6E17D9A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ryan, thanks for the reply! Some comments inline... On 11/20/2017 02:06 PM, Ryan Sleevi wrote: > [...] > I don't think it's fair to suggest that a lack of interest in=20 > addressing the issue as you've framed it supports a conclusion that=20 > there's been no improvements. I think there's been substantial=20 > improvements within the relatively focused communities - as both LAMPS = > and TRANS show - but it may be that you simply disagree on whether=20 > they're improvements. Don't get me wrong, there's been work in many directions - but none=20 really focused on improving the access/scalability/availability of=20 revocation information (to a certain extent). Good work, but I see it=20 more as patches rather than tackling the main issue. In my personal=20 experience, when we tried to tackle revocation issues directly, the=20 answer from WG Chairs or SEC AD was "we are not interested" or "it does=20 not belong here", even when interest was expressed on the mailing=20 list(s). As I say, regrettably, this is my direct personal experience. :-= ( > > [...] > > * *Does anyone remember why the use of non-sequential random > serial number for certificates was introduced ?* Initially, I > think, it was an attempt at masking the number of issued > certificates from a CA. Then, there was some kind of argument > about the "randomness" of data within certificates (that did > not make sense to me, really, since the public key provides > plenty of randomness) - maybe this was combined with the fear > of having "weak" hash algorithms for signing certificates ? > I.e., SHA-1 ? If that is correct, would the use of SHA2 family > (or next gen ones) solve the issue and remove the alleged need > for random serial numbers ? > > This is not a requirement of any IETF documents. > > It is a requirement of various industries - for example, the=20 > CA/Browser Forum's Baseline Requirements - and itself was predated by=20 > various root program requirements that trace their history back to the = > MD5 collisions on 'live' CAs ~2006. > > Much in the same way that some CAs (incorrectly) argued that the=20 > entropy added for MD5 was unnecessary for SHA-1, it seems premature to = > suggest that the entropy is yet again unneeded for SHA-2 (given the=20 > construction similarities). In either event, this represents one of=20 > the few unpredictable fields that cannot be controlled by an attacker=20 > under an adversarial issuance model, and in the world in which all=20 > (Web) issuance should be fully automatic, that is worth considering. Sorry if it was not clear, I was not suggesting that this was a=20 requirement, rather I wanted to verify the story here. Thanks for the=20 clarifications. > [...] > As part of this, the industry's adopted requirements require CAs to=20 > regularly monitor their OCSP systems for such requests as yet another=20 > signal of possible compromise. Maybe I do not fully understand your point, but I think that you just=20 confirmed what I wrote, in some sense... ? The switch in the semantics=20 of the OCSP protocol was/is related to certificate transparency and=20 certificate usage monitoring (i.e., if bad "serial number" are detected, = there might be something weird going on). I guess, but correct me if I=20 am wrong, that what you are saying is that this switch is complementary=20 to CT rather than an initial attempt at CT... ? > > Since in the recent years we developed lots of experience when it > comes to what and how is actually used for revocation checking, I > think we can easily provide simpler designs with lower operational > costs and, consequently, better (more frequent) updates [*] for > revocation information that take all these considerations into > account (in particular, the requirements related to the 2nd > question above have pushed the costs of providing revocation > information - probably an not-intended consequence/side effect). > > I don't think the argument that it's increased the costs is well=20 > supported, and certainly not with respect to the holistic costs of=20 > maintaining "keys to the Internet". Let's put it this way - what if we have a system that does not have to=20 provide signed "tokens" (OCSP responses) for each issued certificates=20 but optimizes for the "valid" case ? In this case, if you run a PKI=20 with, let's say, 100M valid certs of which you have 300K revoked, if you = only have to provide 600K signatures overall, this definitely might=20 change the order of magnitude of the incurred costs in terms of=20 "capacity" (e.g., networking, signing, etc.). I am trying to gather some information from major CAs around this point=20 to understand what the real situation is today :D When / If I manage to=20 get some data around this (if anybody is actually interested), I would=20 be happy to share it with the community. Do you (or anybody on the list) happen to have worked / have experience=20 running large revocation infrastructure ? If so, would you mind sharing=20 your experience (e.g., costs per-certificate for rev info provisioning - = comprising the costs incurred for running or outsourcing the required=20 infrastructure) ? I think it would be useful... > In either event, it's worth noting that significant areas of=20 > performance, privacy, and correctness have been glossed over, and from = > industry, we know these are all substantial concerns that exist with=20 > the revocation infrastructure today. +1 > > [...] > This is all predicated on an assumption of server certificates,=20 > although admittedly, there are many other deployments that exist.=20 > However, it is useful to frame the problem in the intended communities = > - whether server certs, client certs, S/MIME, whether closed intranets = > or public Internet, etc - so that the constraints can be understood=20 > and the potential implementors can be determined. > > [...] > You make very good points here, and I do not disagree :D I am also=20 thinking about other environments where milliseconds are not the issue=20 (IoT) and scalability might be the dominant design requirement. > > [*] Because of this shift in OCSP behavior, CAs now issue OCSP > responses that have validity of up to 7 days, which is definitely > not what OCSP was intended for (usually few minutes, hours or > maybe one day max was initially view > > The industry has long accepted 8 hours as the absolute minimum for=20 > such responses. I also don't think the historic discussion supports=20 > that paranthetical - given that OCSP and CRLs were intended with an=20 > equivalency and CRL publication itself was measured in much longer=20 > timescales. I think that 8 hours is not the same as 7 days :D Big difference there.=20 Also, I would say that CRLs and OCSP responses have very different=20 "implemented semantics" when it comes to the validity period - it is=20 well understood that CRLs should still be checked for updates (as=20 information can become available at any time and certainly within the=20 nextUpdate) while OCSP responses validity are today treated as=20 "cachable" for tor the entire validity period (which, if I read the RFCs = correctly, is not the correct behavior). Unfortunately, the semantics=20 that would "enforce" the correct behavior (omit the nextUpdate in OCSP=20 responses) is not really implemented by today's (Internet) CAs as this=20 might break the (limited) HTTP caching mechanism. Ryan, again, thanks! I really appreciated your good points and the=20 discussion :D Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------BE229C229DDD4A0BE6E17D9A Content-Type: multipart/related; boundary="------------B7CB28CD34A060459B82FF3A" --------------B7CB28CD34A060459B82FF3A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ryan,

thanks for the reply! Some comments inline...

On 11/20/2017 02:06 PM, Ryan Sleevi wrote:
[...]
I don't think it's fair to suggest that a lack of interest in addressing the issue as you've framed it supports a conclusion that there's been no improvements. I think there's been substantial improvements within the relatively focused communities - as both LAMPS and TRANS show - but it may be that you simply disagree on whether they're improvements.
Don't get me wrong, there's been work in many directions - but none really focused on improving the access/scalability/availability of revocation information (to a certain extent). Good work, but I see it more as patches rather than tackling the main issue. In my personal experience, when we tried to tackle revocation issues directly, the answer from WG Chairs or SEC AD was "we are not interested" or "it does not belong here", even when interest was expressed on the mailing list(s). As I say, regrettably, this is my direct personal experience. :-(

[...]
  • Does anyone remember why the use of non-sequential random serial number for certificates was introduced ? Initially, I think, it was an attempt at masking the number of issued certificates from a CA. Then, there was some kind of argument about the "randomness" of data within certificates (that did not make sense to me, really, since the public key provides plenty of randomness) - maybe this was combined with the fear of having "weak" hash algorithms for signing certificates ? I.e., SHA-1 ? If that is correct, would the use of SHA2 family (or next gen ones) solve the issue and remove the alleged need for random serial numbers ?
This is not a requirement of any IETF documents.

It is a requirement of various industries - for example, the CA/Browser Forum's Baseline Requirements - and itself was predated by various root program requirements that trace their history back to the MD5 collisions on 'live' CAs ~2006.

Much in the same way that some CAs (incorrectly) argued that the entropy added for MD5 was unnecessary for SHA-1, it seems premature to suggest that the entropy is yet again unneeded for SHA-2 (given the construction similarities). In either event, this represents one of the few unpredictable fields that cannot be controlled by an attacker under an adversarial issuance model, and in the world in which all (Web) issuance should be fully automatic, that is worth considering.

Sorry if it was not clear, I was not suggesting that this was a requirement, rather I wanted to verify the story here. Thanks for the clarifications.

[...]
As part of this, the industry's adopted requirements require CAs to regularly monitor their OCSP systems for such requests as yet another signal of possible compromise.
Maybe I do not fully understand your point, but I think that you just confirmed what I wrote, in some sense... ? The switch in the semantics of the OCSP protocol was/is related to certificate transparency and certificate usage monitoring (i.e., if bad "serial number" are detected, there might be something weird going on). I guess, but correct me if I am wrong, that what you are saying is that this switch is complementary to CT rather than an initial attempt at CT... ?

Since in the recent years we developed lots of experience when it comes to what and how is actually used for revocation checking, I think we can easily provide simpler designs with lower operational costs and, consequently, better (more frequent) updates [*] for revocation information that take all these considerations into account (in particular, the requirements related to the 2nd question above have pushed the costs of providing revocation information - probably an not-intended consequence/side effect).

I don't think the argument that it's increased the costs is well supported, and certainly not with respect to the holistic costs of maintaining "keys to the Internet".
Let's put it this way - what if we have a system that does not have to provide signed "tokens" (OCSP responses) for each issued certificates but optimizes for the "valid" case ? In this case, if you run a PKI with, let's say, 100M valid certs of which you have 300K revoked, if you only have to provide 600K signatures overall, this definitely might change the order of magnitude of the incurred costs in terms of "capacity" (e.g., networking, signing, etc.).

I am trying to gather some information from major CAs around this point to understand what the real situation is today :D When / If I manage to get some data around this (if anybody is actually interested), I would be happy to share it with the community.

Do you (or anybody on the list) happen to have worked / have experience running large revocation infrastructure ? If so, would you mind sharing your experience (e.g., costs per-certificate for rev info provisioning - comprising the costs incurred for running or outsourcing the required infrastructure) ? I think it would be useful...

In either event, it's worth noting that significant areas of performance, privacy, and correctness have been glossed over, and from industry, we know these are all substantial concerns that exist with the revocation infrastructure today.
+1

[...]
This is all predicated on an assumption of server certificates, although admittedly, there are many other deployments that exist. However, it is useful to frame the problem in the intended communities - whether server certs, client certs, S/MIME, whether closed intranets or public Internet, etc - so that the constraints can be understood and the potential implementors can be determined.
[...]
You make very good points here, and I do not disagree :D I am also thinking about other environments where milliseconds are not the issue (IoT) and scalability might be the dominant design requirement.

[*] Because of this shift in OCSP behavior, CAs now issue OCSP responses that have validity of up to 7 days, which is definitely not what OCSP was intended for (usually few minutes, hours or maybe one day max was initially view=C2=A0

The industry has long accepted 8 hours as the absolute minimum for such responses. I also don't think the historic discussion supports that paranthetical - given that OCSP and CRLs were intended with an equivalency and CRL publication itself was measured in much longer timescales.

I think that 8 hours is not the same as 7 days :D Big difference there. Also, I would say that CRLs and OCSP responses have very different "implemented semantics" when it comes to the validity period - it is well understood that CRLs should still be checked for updates (as information can become available at any time and certainly within the nextUpdate) while OCSP responses validity are today treated as "cachable" for tor the entire validity period (which, if I read the RFCs correctly, is not the correct behavior). Unfortunately, the semantics that would "enforce" the correct behavior (omit the nextUpdate in OCSP responses) is not really implemented by today's (Internet) CAs as this might break the (limited) HTTP caching mechanism.

Ryan, again, thanks! I really appreciated your good points and the discussion :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------B7CB28CD34A060459B82FF3A Content-Type: image/png; name="amckoeeejmocdhig.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="amckoeeejmocdhig.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------B7CB28CD34A060459B82FF3A-- --------------BE229C229DDD4A0BE6E17D9A-- --------------ms080204040108010903080603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MjAyMzI3MzdaMC8GCSqGSIb3DQEJBDEiBCCvZyc3Q5ly2Xc3u+ueXm9R5e5EO6qh8z6K3XJj L7A6TTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBACKBvWbxW9M0F9+h njwNW/zKkJKY4hap6qybmggQxPp8xlKiFU2eeyzMNp54RGy8N8c7QP+11p7rfYoMte26D/Q9 WSItMNQSnbdTWRre9wITAxueUKKJ5vYzVx2wx2xNJM75riDxXz/hN7lJtX4MwnjJn6tGIsFy LZWBGp7rmf8d4X9R/Qw45y3lrMEYfYGiT4rrSaIpbwOzjU0JgZZH0NlSk4zzH1j5iOrAGdTV UV2E1Jm2iTvxhTlb0yZf/95dNodpgl4r05WdWYmOlKasc08mFtugWcEOMg/DQAOd4W4qbstg XKFvuWldxYfEynb55Dsyek/7Q2ySJ3EVwRtn2JYAAAAAAAA= --------------ms080204040108010903080603-- From nobody Sun Nov 26 09:03:18 2017 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808B7129438; Sun, 26 Nov 2017 09:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 398qCYvwOlXs; Sun, 26 Nov 2017 09:03:15 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 E4C23129435; Sun, 26 Nov 2017 09:03:14 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g130so25622602wme.0; Sun, 26 Nov 2017 09:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K4ZDXmQoM3Wrnz8yK/0H2AuMdpO7FbP6e4RqjITTa/0=; b=qtzINDQXr/e0THMwLVh9arnyQkUulDB6EqJ+o4VDNjoWNuRhrgunsICa66Sa/pLbw8 UeJKKFxc0cbMUk/rkOsE4YPZqpPwJMBFMAQD6ptOQiapX4mR6wvFpSXNQ8lUDfVbh5aG HK2yPt+8roFf4Cl8PwOsyDHCF4oBBxXygdWFPIhGFhEMzMHmEXcvsMgN68V64SGZnDEX Qts6axmTzKYhMm19DZ/TV03T3gwDFl8vZnRfPHGrGfN6ZLXMdIhZGIj4ecImfXG6Qjx1 B7SoKFklZ5w4f+v4vYOOkzIi/jxuhmHSaTZYxsay+K1mXRwzduWTBJedfSfdfjilYhau Deag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K4ZDXmQoM3Wrnz8yK/0H2AuMdpO7FbP6e4RqjITTa/0=; b=e6aN0tu8IiW5c7O6XstLnl8FWeboM6oLmR4EqK2fR4ekUbETNyMirVvyw2gjmyTTZZ tJz8lfj+IgPqAjqZODDLwgeSbH2ZR/WiK9HMKeFAaxrR+FpnA9iCru/Teaps9JbaCBdK Bhh6RxQiibnCzX5dMBz0mYIDtzSDiXtR9gxcR7VkYeO5uPqUNIUxbbUn4okz1ZVg4CHz lMuWWjIi2dy/l4+hnIcwRpKpu7x43B02ihJHBvIgoDK6va3YzgHudFj6vilY0xlQAt1y 8fgYV9kWm43yqlxmMeiLWJ4xVmtD2rV4UrBpuF3cAZ/o8+lOQDCnUyDN8+6pLmf8W1Nx pRgg== X-Gm-Message-State: AJaThX4jGbOJ8gfeFjyVQLN1WW5xuKMIo4cKzlsswnHyWJxFcmWTs9Jz NvLsEozVRmfycZR6vSHgvJPuZRTiU6sHb3zg8lhv2VHc X-Google-Smtp-Source: AGs4zMYw9Q3OolGqjb8J1vPyeJ93+//toS9Zm+MWQKk4c418E9vBRzdm+clvFAUM+LwHIlpze9ZqizuOhMhn59A03Uk= X-Received: by 10.80.208.195 with SMTP id g3mr48518595edf.246.1511715793362; Sun, 26 Nov 2017 09:03:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.139.216 with HTTP; Sun, 26 Nov 2017 09:03:12 -0800 (PST) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sun, 26 Nov 2017 20:03:12 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: LAMPS , pkix@ietf.org, dev-security-policy@lists.mozilla.org, "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd2fadd64dc055ee5c28b" Archived-At: Subject: Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 17:03:17 -0000 --94eb2c1cd2fadd64dc055ee5c28b Content-Type: text/plain; charset="UTF-8" Hello, I've just uploaded the new version of my draft. The main difference from the previous one is more or less described syntax of specific limitations mentioned in text. The answers on the question raised by Nikos are below. ================= A new version of I-D, draft-belyavskiy-certificate-limitation-policy-05.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 05 Title: Certificate Limitation Policy Document date: 2017-11-25 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy- certificate-limitation-policy-05.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy- certificate-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate- limitation-policy-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy- certificate-limitation-policy-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy- certificate-limitation-policy-05 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. ================== On Thu, Oct 12, 2017 at 3:03 PM, Nikos Mavrogiannopoulos via dev-security-policy wrote: > On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky > wrote: > > Dear Nicos, > > > > Sorry for the delay with my response. > > > > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos < > nmav@gnutls.org> > > wrote: > >> > >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky > >> wrote: > >> > > > > Well, the specification I suggest should allow applying CLPs issued by > major > > vendors (Mozilla etc). > > For this purposes the CLPs should be validable => signed. > > Hi, > If mozilla or any other organization is willing to deploy such PKI, > that would be great. However for the majority of software, I'd expect > that such files are distributed using the same channel as software, > and thus using the same authentication mechanism for it rather than a > new PKI. For a software distributor to use that optional signing could > work. > I got your point. I'll think about allowing local CLPs to be unsigned. > > >> One problem with that is the fact that the existing CRL extensions are > >> about extending attributes of the CRL, rather than adding/removing > >> attributes to the certificate in question. > > For this purposes I implied that the limitations are provided not by > > extensions, > > but as SEQUENCE of limitations related to the certificates. > > > > Was I wrong in the ASN1 scheme in the current version of my draft? > > I do not think that the presented ASN.1 description is valid. > The "limitations SEQUENCE," doesn't define anything in ASN.1 > (i..e, it is a sequence of what?). > I (hopefully) clarified the ASN.1 description in the new version. > > >> > >> To bring the stapled extensions to your proposal, you'd need the > >> Extensions and Extension fields from RFC5280, and > >> add into limitedCertificates structure (I'll split it on the example > >> below for clarity) the following field. > >> > >> LimitedCertificates ::= SEQUENCE OF LimitedCertificate > >> > >> LimitedCertificate ::= SEQUENCE { > >> userCertificate CertificateSerialNumber, > >> certificateIssuer Name, > >> limitationDate Time, > >> limitationPropagation Enum, > >> fingerprint SEQUENCE { > >> fingerprintAlgorithm AlgorithmIdentifier, > >> fingerprintValue OCTET STRING > >> } OPTIONAL, > >> limitations SEQUENCE, > >> } OPTIONAL, > >> }; > >> > >> > >> stapledExtensions Extensions; <----- NEW > >> } > > > > > > Sorry, I do not get the difference between the purposes of the field > > 'limitations' > > and 'stapledExtensions'. > > I cannot answer this as I cannot see the syntax of the limitations > field. I thought it was a field intended to spark discussion rather > than anything specific. > Now, when the syntax is provided, I hope it's specific enough to continue the discussion. -- SY, Dmitry Belyavsky --94eb2c1cd2fadd64dc055ee5c28b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've just uploaded the new v= ersion of my draft.

The main difference from the p= revious one is more or less described syntax of=C2=A0
specific li= mitations mentioned in text.=C2=A0

The answers= on the question raised by Nikos are below.

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A new version of I-D, draft-belyavskiy-certificate-limitation-po= licy-05.txt
has been successfully submitted by Dmitry Belyavskiy and posted to t= he
IE= TF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-belyavskiy-certificate-limitation-policy
Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation = Policy
Document date:=C2=A0 2017-11-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indiv= idual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/inte= rnet-drafts/draft-belyavskiy-certificate-limitation-policy-0= 5.txt
St= atus:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ie= tf.org/doc/draft-belyavskiy-certificate-limitation-policy/Htmlized:=C2= =A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-b= elyavskiy-certificate-limitation-policy-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2= =A0https://datatracker.ietf.org/doc/html/draft-be= lyavskiy-certificate-limitation-policy-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2= =3Ddraft-belyavskiy-certificate-limitation-policy-05

Abstract:
=C2=A0 =C2=A0The document provides a specification of the a= pplication-level trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the applicati= on level, the limitations of
=C2=A0 =C2=A0trust can be distributed separately us= ing cryptographically protected
=C2=A0 =C2=A0format instead of hardcoding the ch= ecks into the application itself.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>

On Thu, Oct 12, 2017 at 3:03 PM, Nik= os Mavrogiannopoulos via dev-security-policy <dev-sec= urity-policy@lists.mozilla.org> wrote:
On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Dear Nicos,
>
> Sorry for the delay with my response.
>
> On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
> wrote:
>>
>> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <beldmit@gmail.com>
>> wrote:
>>
>
> Well, the specification I suggest should allow applying CLPs issued by= major
> vendors (Mozilla etc).
> For this purposes the CLPs should be validable =3D> signed.

Hi,
=C2=A0If mozilla or any other organization is willing to deploy such PKI, that would be great. However for the majority of software, I'd expect that such files are distributed using the same channel as software,
and thus using the same authentication mechanism for it rather than a
new PKI. For a software distributor to use that optional signing could
work.

I got your point. I'll think = about allowing local CLPs to be unsigned.
=C2=A0

>> One problem with that is the fact that the existing CRL extensions= are
>> about extending attributes of the CRL, rather than adding/removing=
>> attributes to the certificate in question.
> For this purposes I implied that the limitations are provided not by > extensions,
> but as SEQUENCE of limitations related to the certificates.
>
> Was I wrong in the ASN1 scheme in the current version of my draft?

I do not think that the presented ASN.1 description is valid.
The "limitations=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE," doe= sn't define anything in ASN.1
(i..e, it is a sequence of what?).

I (h= opefully) clarified the ASN.1 description in the new version.
=C2= =A0

>>
>> To bring the stapled extensions to your proposal, you'd need t= he
>> Extensions and Extension fields from RFC5280, and
>> add into limitedCertificates structure (I'll split it on the e= xample
>> below for clarity) the following field.
>>
>> LimitedCertificates=C2=A0 ::=3D=C2=A0 =C2=A0SEQUENCE OF LimitedCer= tificate
>>
>> LimitedCertificate ::=3D SEQUENCE {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0userC= ertificate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateSerialNumber,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0certi= ficateIssuer=C2=A0 =C2=A0 =C2=A0 =C2=A0Name,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ationDate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ationPropagation=C2=A0 =C2=A0Enum,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0finge= rprint SEQUENCE {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0fingerprintAlgorithm AlgorithmIdentifier,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0fingerprintValue=C2=A0 =C2=A0 =C2=A0OCTET 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 } OPTION= AL,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ations=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE,
>>=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 } OPTIONAL,
>>=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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stapl= edExtensions Extensions; <----- NEW
>> }
>
>
> Sorry, I do not get the difference between the purposes of the field > 'limitations'
> and 'stapledExtensions'.

I cannot answer this as I cannot see the syntax of the limitations field. I thought it was a field intended to spark discussion rather
than anything specific.

Now, when the s= yntax is provided, I hope it's specific enough to continue the discussi= on.

--=C2=A0
SY, Dmitry Belyavsky
--94eb2c1cd2fadd64dc055ee5c28b--