From nobody Thu Feb 11 11:53:10 2021 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46B13A18C0 for ; Thu, 11 Feb 2021 11:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sN4s1hmHKTYG for ; Thu, 11 Feb 2021 11:53:06 -0800 (PST) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (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 034323A18BA for ; Thu, 11 Feb 2021 11:53:05 -0800 (PST) Received: by mail-pf1-f180.google.com with SMTP id x136so4376423pfc.2 for ; Thu, 11 Feb 2021 11:53:05 -0800 (PST) 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=cyc/8BlRB0JUH2605B6xhmAQTEmrYQmfXG11jdKYwhg=; b=po9JaD4lYHWFHe6pbkHcSS/bJTjORbKyVl6aS2MtXO4+hbAG9K8Ijx7z4GbTThVirp INKvQzx+1gHIJD1obbQZXQBIE1z69HUyrJHpOjEeGUACltaVOMbU3dyOY4Tbr7XHcjZE QAQl1vYtB1aQJXqfizowL4M+G675WkGuHTEgvKjwWhmnANJkf5TIaGgtTjqknMSkMH20 uNKV6oqgYCSfgITAOtk1+zn3Kcb5Vlz6KX/yzVFcMgSrJaz229XwqR/iT5N0l42c0lxG X+DLcXZ0pIDXZFCf5QY+wAo5EcnAGjSjQCjuR9IweIVXU7OEC8tHUvsK2re/WyDqs2FR CXDQ== X-Gm-Message-State: AOAM532mbm3YRmdfEljd9PNlj8ZH1akY6O7KFkL0HRDNqEdebVnWhrl9 NcX/abiPuT0T2ByTlrjeXzUjJ8NYsKg= X-Google-Smtp-Source: ABdhPJwG3a7DVrP5zVqjifLF/CnJdVWIeBVLc/oS2z3jx344Hnd407gD5uIka65kZYgdOexar+hDZQ== X-Received: by 2002:a05:6a00:8f:b029:1e8:6975:395e with SMTP id c15-20020a056a00008fb02901e86975395emr48846pfj.55.1613073185178; Thu, 11 Feb 2021 11:53:05 -0800 (PST) Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com. [209.85.215.180]) by smtp.gmail.com with ESMTPSA id h1sm6957080pgj.59.2021.02.11.11.53.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Feb 2021 11:53:04 -0800 (PST) Received: by mail-pg1-f180.google.com with SMTP id t26so4663570pgv.3 for ; Thu, 11 Feb 2021 11:53:04 -0800 (PST) X-Received: by 2002:a63:d855:: with SMTP id k21mr9485545pgj.399.1613073184535; Thu, 11 Feb 2021 11:53:04 -0800 (PST) MIME-Version: 1.0 References: <9D01B155-6BB8-4438-8FAA-149686B69B64@vigilsec.com> <7F1A001A-C6D4-4F6C-B2D6-1FA43E4900B8@akamai.com> <1D13C815-387F-4FAD-A71F-79C3DEC11A22@akamai.com> <87F0EF4C-205C-4D5D-9849-ADD13BC0FB83@vigilsec.com> In-Reply-To: <87F0EF4C-205C-4D5D-9849-ADD13BC0FB83@vigilsec.com> From: Ryan Sleevi Date: Thu, 11 Feb 2021 14:52:53 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Ryan Sleevi , LAMPS Content-Type: multipart/alternative; boundary="0000000000002941b605bb14de53" Archived-At: Subject: Re: [lamps] Proposed recharter text X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:53:08 -0000 --0000000000002941b605bb14de53 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 11, 2021 at 2:20 PM Russ Housley wrote: > I do not agree with your characterization of the extendedKeyUsage concern, > but I do agree that implementation in CA certificates does not match RFC > 5280. I proposed a solution to this situation some years ago, but > implementers did not want to change. In addition, RFC 5280 is a profile of > X.509, so RFC 5280 should not specify a different behavior than X.509. I > continue to believe that a different OID should be used if a different > behavior is desired. > Russ, Thanks for helping emphasize the points I'm making, on both points. 2459/3280/5280 emerged in parallel to existing implementations of "PKI things", whether it be SSLeay, 'the code that would become" Mozilla NSS, the "IE code that became CryptoAPI", etc. Rich can speak better to/for OpenSSL, but I would suggest that, for a number of implementations of "certificate things", the goal was not "implement X.509v3", nor "implement 5280", but "implement enough for TLS". While it's true that there used to be more diversity of implementations that purely targeted 5280 (and the abstract goals), and certainly Microsoft's efforts on CryptoAPI and Sun-Oracle's on Java eventually circled to "implement everything spec'd in 5280", the reality is that much of the running code does not and has not had 5280 as the target for interoperability. This is to the point (2). Efforts during the 2459/3280/5280 work each tried to bring this issue re: EKUs, and resolve, and the reaction you raise now was much the same then: "If you want this, you should do something different" - yet the implementers had already implemented their logic, and it was the immovable object of objections like you raise here that ultimately lead these behaviors not to appear in the specs, yet still lead to all sorts of surprising interactions and potential risks (e.g. Flame, which was both in part possible and mitigated due to this EKU chaining behaviour). > Internationalization is hard. This was the outcome of many very long > discussions. This is an area where RFC 5280 could be improved but > stringPrep was the advice from the ART Area folks at the time. > This isn't strictly about internationalization, though. This was about trying to bend over backwards with existing certificates/PKIs, while trying to get stuff to use the internationalization-capable "new" features. This is readily clear through RFC 2459's language, which 3280 inherited, which set that migration date of December 31, 2003 - but tried to maintain backwards compat. 5280 significantly altered this with the StringPrep, but still, my point was that this "feature" is ***only*** relevant if you're: a) Trying to use The Directory to look up certificates, and thus needing to use DAP/LDAP b) Trying to ensure all (new) certificates conform to a particular profile, without requiring the replacement of existing root/intermediate certificates. My point in highlighting this was that twenty years later, we know (a) is largely not true in a "PKIX" sense, even if it remains true for a number of enterprise PKIs. Equally, we know that (b) was a giant own-goal to the goal it was trying to achieve, because rather than encouraging transition, implementations just kept the non-UTF8String approaches around. So when revisiting 5280, and asking in the context of (3), it's reasonable to ask "Is this feature a product of design assumptions re: The Directory, and thus suitable to cut, or is this feature essential simply because it's used in a non-Internet-wide-PKI-sense". And, in the context of (1), where this varies greatly, "Does this feature prevent us from progressing to Internet Standard". Concretely, an alternative would be to simply do what other PKI communities have done (including the CA/B Forum), and which reflect the algorithm of 2459/3280, which is to say "memcmp() is the only comparison function", which works as equally fine for UTF8String as it does for PrintableString. Again, I'm not particularly excited to revisit all of this, precisely because this is a tremendous amount of effort. As it relates, however, to the discussion relevant to the charter, I'm suggesting that if folks aren't looking for multiple years of debate and relitigation, then the draft charter should provide better guidance for what is in scope and out of scope, so that we can resolve such discussions as early as possible, before they suck up years of effort and energy. The last time the IETF touched these docs, PKI was the old-Blockchain, and the excitement led to everything and the kitchen sink being included. Do we still pretend that's the case, in order to progress far enough to make the "minor" adjustments may not (and may never) reflect implementations, or do we accept the Internet has changed since 2005, and try to adjust how implementations have evolved, even if that will take us years? --0000000000002941b605bb14de53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 11, 2021 at 2:20 PM Russ Housley <housley@vigilsec.com> wrote:
=
I do not agree with = your characterization of the extendedKeyUsage concern, but I do agree that = implementation in CA certificates does not match RFC 5280.=C2=A0 I proposed= a solution to this situation some years ago, but implementers did not want= to change.=C2=A0 In addition, RFC 5280 is a profile of X.509, so RFC 5280 = should not specify a different behavior than X.509.=C2=A0 I continue to bel= ieve that a different OID should be used if a different behavior is desired= .

Russ,

Thanks for helping emphasize the points I'm making, on both points. 2= 459/3280/5280 emerged in parallel to existing implementations of "PKI = things", whether it be SSLeay, 'the code that would become" M= ozilla NSS, the "IE code that became CryptoAPI", etc. Rich can sp= eak better to/for OpenSSL, but I would suggest that, for a number of implem= entations of "certificate things", the goal was not "impleme= nt X.509v3", nor "implement 5280", but "implement enoug= h for TLS". While it's true that there used to be more diversity o= f implementations that purely targeted 5280 (and the abstract goals), and c= ertainly Microsoft's efforts on CryptoAPI and Sun-Oracle's on Java = eventually circled to "implement everything spec'd in 5280", = the reality is that much of the running code does not and has not had 5280 = as the target for interoperability.

This is to the= point (2). Efforts during the 2459/3280/5280 work each tried to bring this= issue re: EKUs, and resolve, and the reaction you raise now was much the s= ame then: "If you want this, you should do something different" -= yet the implementers had already implemented their logic, and it was the i= mmovable object of objections like you raise here that ultimately lead thes= e behaviors not to appear in the specs, yet still lead to all sorts of surp= rising interactions and potential risks (e.g. Flame, which was both in part= possible and mitigated due to this EKU chaining behaviour).
=C2= =A0
Internationalization is hard. This was the o= utcome of many very long discussions. This is an area where RFC 5280 could = be improved but stringPrep was the advice from the ART Area folks at the ti= me.=C2=A0=C2=A0

This isn't = strictly about internationalization, though. This was about trying to bend = over backwards with existing certificates/PKIs, while trying to get stuff t= o use the internationalization-capable "new" features. This is re= adily clear through RFC 2459's language, which 3280 inherited, which se= t that migration date of December 31, 2003 - but tried to maintain backward= s compat.

5280 significantly altered this with the= StringPrep, but still, my point was that this "feature" is **= only**=C2=A0relevant if you're:
a) Trying to use The Dire= ctory to look up certificates, and thus needing to use DAP/LDAP
b= ) Trying to ensure all (new) certificates conform to a particular profile, = without requiring the replacement of existing root/intermediate certificate= s.

My point in highlighting this was that twenty y= ears later, we know (a) is largely not true in a "PKIX" sense, ev= en if it remains true for a number of enterprise PKIs. Equally, we know tha= t (b) was a giant own-goal to the goal it was trying to achieve, because ra= ther than encouraging transition, implementations just kept the non-UTF8Str= ing approaches around.

So when revisiting 5280, an= d asking in the context of (3), it's reasonable to ask "Is this fe= ature a product of design assumptions re: The Directory, and thus suitable = to cut, or is this feature essential simply because it's used in a non-= Internet-wide-PKI-sense". And, in the context of (1), where this varie= s greatly, "Does this feature prevent us from progressing to Internet = Standard". Concretely, an alternative would be to simply do what other= PKI communities have done (including the CA/B Forum), and which reflect th= e algorithm of 2459/3280, which is to say "memcmp() is the only compar= ison function", which works as equally fine for UTF8String as it does = for PrintableString.

Again, I'm not particular= ly excited to revisit all of this, precisely because this is a tremendous a= mount of effort. As it relates, however, to the discussion relevant to the = charter, I'm suggesting that if folks aren't looking for multiple y= ears of debate and relitigation, then the draft charter should provide bett= er guidance for what is in scope and out of scope, so that we can resolve s= uch discussions as early as possible, before they suck up years of effort a= nd energy.

The last time the IETF touched these do= cs, PKI was the old-Blockchain, and the excitement led to everything and th= e kitchen sink being included. Do we still pretend that's the case, in = order to progress far enough to make the "minor" adjustments may = not (and may never) reflect implementations, or do we accept the Internet h= as changed since 2005, and try to adjust how implementations have evolved, = even if that will take us years?
--0000000000002941b605bb14de53--