[OAUTH-WG] Re: Call for adoption - PIKA

Giuseppe De Marco <demarcog83@gmail.com> Tue, 18 June 2024 07:31 UTC

Return-Path: <demarcog83@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097B7C14F711 for <oauth@ietfa.amsl.com>; Tue, 18 Jun 2024 00:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level:
X-Spam-Status: No, score=-1.857 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu-KzHGy-x91 for <oauth@ietfa.amsl.com>; Tue, 18 Jun 2024 00:31:30 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13E3C14F616 for <oauth@ietf.org>; Tue, 18 Jun 2024 00:31:29 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-57ccd1111aeso2947115a12.0 for <oauth@ietf.org>; Tue, 18 Jun 2024 00:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718695888; x=1719300688; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XFF5z2srEyA8PDbvE7fhdy9uYinArvZ7RNrINvilwTM=; b=h1vfFNEOdFB2MvukSAOjmYgJr78CYRPcm0xgajXcV2guLsKNMJrTfrdiwo/ER9IGPL 10uXjB+ydeSfyVzUFViNguCOgfrRBH+9bwiS5C+EQRlMJY03kCsLFAqA0m4y3x4eQkAZ rDG8HvHSZsJduEnbPUMwRo3LJHwVinsfIFPBboKqrGtaTsHhWoTO9xHI1ovRx/tjYKNp 8IMoG9l8Bg5HgBK2IU6Yz4h0+0b1cXlJ3xNsCjvAcavEY2pHewuReI/GLgQjDJKYfGvD aCxA1l0/gB9xekXlyt7eP7CTcRJh4iAikrTMj8yOoGPNakpxkj7B9Pi7tiBC4wAK3oOm TaPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718695888; x=1719300688; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XFF5z2srEyA8PDbvE7fhdy9uYinArvZ7RNrINvilwTM=; b=bkj2qQHeA6hxdfgxAg6yHqC+QmkmEKqxDKHuBV6+4NPz5BAm4WzmkFyYbLPCGj/W4o LuUOZS94VS3Hg/9MYvqxwekoFUJndIVHepeMs42LBHm1A1lx0xuhKK4mz8MlPBfNdGKq 06GFHmj7DuzBSarC53luYLePDocNloO2eb0XaeJ9nL9QhkbjX76wPd6TDYhoysvL/Fbl M79J+e0ge8Nw7GsSDz8702CBUappIzM7iSxYJgiSQoZG6sgb9slaOGuWjJr2OXATJESr C0hxSFLUEuIiBoOv6YU5fm0urNtxm2Elpjcf4zTUYQ0QgXUBltQYaBAqeeyJQBanOU3o dz1Q==
X-Forwarded-Encrypted: i=1; AJvYcCWUqKNYXIPBQ0viRbq9s8sEWuKzhd3zDCnVoeNX/8XZdYzvuVnfDx1PmJs/wKplg0jjC5kIJUL0v0FG41LGWg==
X-Gm-Message-State: AOJu0YxjOtNLXJvLFIpqgXW92r5z+umVU3NdWqRNDOXsyo5uLtHS6oro EBqWReCmcIh3CoXC1ghqvlmonwJVuEsZmZ5OrK11g+A77+tBOYij1lddFT+x29xDTBgZHWzaDwj Xsb7b1O+W+92DT+2pN/dTL8hbw18=
X-Google-Smtp-Source: AGHT+IFno+DwkO8w0kmLdBxyAWwH35K9JqBIW4g39/idj7pZkyg2msfBGGdWIz4sJ0x1dPxUGaz76r0NO1nHEzEcd7Q=
X-Received: by 2002:a50:d5c2:0:b0:57c:5ec6:1466 with SMTP id 4fb4d7f45d1cf-57cbd67dbdfmr8156004a12.25.1718695887580; Tue, 18 Jun 2024 00:31:27 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP9GmF4vp1uzLXK0YYZAHUDjK7RHbhEb4MCXkB7N3Oq4+w@mail.gmail.com> <CAL02cgSEt8z3zsLC6U5eqhMSHbn-+7uywZCQUrUpJ9zQwQeShQ@mail.gmail.com> <SJ0PR02MB74398B6C188C5D374B86F81BB7C72@SJ0PR02MB7439.namprd02.prod.outlook.com> <CAL02cgTMSgi-boxZAjkFc8_JrEJrGzk=LH5BnS2Earx-Ji2j9A@mail.gmail.com> <SJ0PR02MB74398BDC255CC7D533FC3149B7C72@SJ0PR02MB7439.namprd02.prod.outlook.com> <CACsn0c=TH=YyLRPaZXzd=oD1ZSm2-yvA1WxpxcMe6kLm=JwrNQ@mail.gmail.com> <CAK2Cwb6V_biszxSqxaykFDTowAD2STpzts=48=Rd_KeMie3+Ug@mail.gmail.com> <CAP_qYynE8wuvVCCBKFJai8LshMC5qY3PrNXYCOwnTq5C0gRyFQ@mail.gmail.com> <CAKoiRuaRQUL0qA6oM5v3jzjEm5an0-OK=wEoqk1u7iZmgQEuRQ@mail.gmail.com> <CAP_qYy=RbZwB+36gNTBiBDdDeKrxGxmp-+1L+4UZxoakuaC1nQ@mail.gmail.com> <CAKoiRua_yeSzHrBJ0SwLnQr9P9MDUnTEejqi+kEL6Hd_1s5Jsg@mail.gmail.com> <CAP_qYykfZyb5JbzPjE0tPwMxHC-7G01fiX9Jq-Y0xtnBc4ee6A@mail.gmail.com> <CAK2Cwb53mPKJqdfY338qKF4s0Q9yxVfFErcsMKUMfphzHPvE-w@mail.gmail.com>
In-Reply-To: <CAK2Cwb53mPKJqdfY338qKF4s0Q9yxVfFErcsMKUMfphzHPvE-w@mail.gmail.com>
From: Giuseppe De Marco <demarcog83@gmail.com>
Date: Tue, 18 Jun 2024 09:31:16 +0200
Message-ID: <CAP_qYymV-7WfTv=0Q-8ZSH+L5_KPXM-YV+Uq2vkmUws=5HC7RA@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000db3402061b2511ae"
Message-ID-Hash: YPCVPJBNDGVHYXSGUKKTJ3Y4DPIFWRZT
X-Message-ID-Hash: YPCVPJBNDGVHYXSGUKKTJ3Y4DPIFWRZT
X-MailFrom: demarcog83@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Rohan Mahy <rohan.mahy@gmail.com>, oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KZg5jp5uMXuKbjVdUEVfp4MQpjk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Technology alone cannot solve this problem unless a mapping of different
trust frameworks and rules to handle all behaviors/cases is defined and
voluntarily adopted. The parties must be aware that they are dealing with
an entity operating under a different trust framework, and they must
evaluate whether they recognize and support that framework, and determine
which rules to apply.

There are projects actively working in this field to develop an
interoperability profile between multiple frameworks, such as SIDI HUB.

Il giorno gio 13 giu 2024 alle ore 03:13 Tom Jones <
thomasclinganjones@gmail.com> ha scritto:

> But the core problem is all of the trust frameworks, like federation, roll
> their own conditions and freshness/revocation mechanisms. In other words if
> the same attributes from one trust framework were passed to an alternative
> framework, it is likely to fail.  There is no interop even under
> consideration.
>
> ..tom
>
> thx ..Tom (mobile)
>
> On Wed, Jun 12, 2024, 5:39 AM Giuseppe De Marco <demarcog83@gmail.com>
> wrote:
>
>> Hi Rohan,
>>
>> I'ìm very bad in giving answers, I have to live with this, please accept
>> my excuse (it is almost certainly an attention disorder, autism or
>> something).
>>
>> Therefore here I try the Take 2.
>>
>> > Today relying parties verify the issue domain indirectly by opening a
>> TLS connection to the https URL of the issuer, which involves an X.509
>> validation of the issuer domain name in the URL.
>>
>> Amen. this give us the certaininty that the subject is exactly the one
>> we're supposing to interact with, untill the DNS were not compromised and
>> an evil endpoint with let's encrypt would appear on the way. Therefore the
>> decision about  the trust anchor to trust is crucial.
>> At the same time I use to trust (and love) let'sencrypt, therefore
>> addings additional layers helps me in supporting all the CAs attested in
>> the CAB forum and at the same time add additional security, policy and
>> interoperability chjecks using another layer.
>>
>> > What is the problem with the relying party taking a certificate and
>> validating the issue domain name directly using the same certificate?
>>
>> it is not a problem but a requirement. The relying party MUST do this.
>> After doing this and got the assurance asbout the domain name, a more
>> advanced trust establishment may occur where requirements need this.
>> I have this requirements.
>>
>> A Friend sent to me a picture of a mushroom he has picked. An popular
>> cloud provider, using AI, attested it as very good for cooking.
>> He didn't trust that "trust anchor" even if so popular and fancy,
>> therefore he has double checked with me.
>> According to my experience that mushroom was an amanita muscaria. It's
>> still a mushroom, but you cannot attest the compliance of it to your needs
>> if you don't add additional checks.
>>
>> additional layers for additional frameoworks and compliance checks
>> satisfy the requirements of having additional checks for additional
>> property, not covered with the minimal set of requirement, like be a
>> mushroom or a FQDN using TLS.
>>
>> Another example
>>
>>
>> Il giorno mer 12 giu 2024 alle ore 14:09 Rohan Mahy <rohan.mahy@gmail.com>
>> ha scritto:
>>
>>> Hi,
>>> This is all interesting in terms of a larger view of big picture goals
>>> of authentication, but you didn't answer my question. Today relying parties
>>> verify the issue domain indirectly by opening a TLS connection to the https
>>> URL of the issuer, which involves an X.509 validation of the issuer domain
>>> name in the URL. What is the problem with the relying party taking a
>>> certificate and validating the issue domain name directly using the same
>>> certificate?
>>>
>>> Thanks,
>>> -rohan
>>>
>>> On Wed, Jun 12, 2024 at 7:59 AM Giuseppe De Marco <demarcog83@gmail.com>
>>> wrote:
>>>
>>>> This depends on the evaluation criteria of the verification you conduct
>>>> with a subject.
>>>>
>>>> We can agree that the initial verifiable evidence that a Trust
>>>> Anchor/CA has issued a certificate for a subject is the first indication
>>>> that the subject belongs to a network/framework/shared-regulation/perimeter.
>>>>
>>>> Let's consider this mailing list as a trust anchor.
>>>>
>>>> We're having a productive conversation under a common trust anchor,
>>>> where the evidence that connects us is our membership in this community,
>>>> under the IETF Trust Anchor.
>>>>
>>>> However, this alone is not sufficient, because you must read everything
>>>> I say and empirically evaluate if you can trust me qualitatively.
>>>>
>>>> OpenID Federation allows the exchange of metadata to securely establish
>>>> interoperability and also applies policies that dynamically change this
>>>> metadata, adding qualitative evidence with trust marks.
>>>>
>>>> This is the advancement I found that the X.509 based PKI was not
>>>> designed for. I use X.509 based PKI for other purposes, since in this
>>>> universe everything has its right place, and I appreciate this.
>>>>
>>>> I also appreciate PIKA in a way to make this grow and get integrated
>>>> with other models that should not be kept out of the scope of the
>>>> specification if you agree and if we may have the opportunity to work
>>>> together in this field
>>>>
>>>> Il giorno mer 12 giu 2024 alle ore 12:47 Rohan Mahy <
>>>> rohan.mahy@gmail.com> ha scritto:
>>>>
>>>>> Giuseppe,
>>>>> Given that verifying the issuer is already done using X.509 PKI today,
>>>>> why do you object to trusting the PKI root for the same purpose (validating
>>>>> the domain name of the issuer) with the same validity period (between the
>>>>> notBefore and notAfter of the certificate)?
>>>>>
>>>>> Thanks,
>>>>> -rohan
>>>>>
>>>>> On Tue, Jun 11, 2024 at 4:44 AM Giuseppe De Marco <
>>>>> demarcog83@gmail.com> wrote:
>>>>>
>>>>>> Ciao Tom,
>>>>>>
>>>>>> Public Key Infrastructure satisfies the requirements to provide
>>>>>> public keys. Technically, using X.509 certificates represents a
>>>>>> consolidated approach.
>>>>>> Giving public keys doesn't help in establishing the trust or fully
>>>>>> proving the compliance to shared rules, that's why openid federation
>>>>>> authors insist that openid federation is not only a pki.
>>>>>>
>>>>>> TLS is not removed, we use X.509 based pki on the web, therefore also
>>>>>> using federation.
>>>>>>
>>>>>> TLS is used to establish confidentiality with an endpoint,
>>>>>> establishing trust to a subject only because it controls a private
>>>>>> cryptographic key is similar to the weakness about the bearer tokens.
>>>>>> Therefore, for instance, in advanced ecosystems and implementation is
>>>>>> required to demonstrate the proof of possession of the tokens because
>>>>>> bearers alone are not secure enough. This is more complex but required in
>>>>>> the real wold.
>>>>>>
>>>>>> The point is: what is trust, how to establish trust in the real
>>>>>> world, which are the technical layers that we should (even in a modular
>>>>>> way) take into account to achieve our goals. Do we have the same goals?
>>>>>> Don't stop working together, let's keep the conversation to achieve
>>>>>> our goals in an harmonic way.
>>>>>>
>>>>>> Il giorno mar 11 giu 2024 alle ore 06:11 Tom Jones <
>>>>>> thomasclinganjones@gmail.com> ha scritto:
>>>>>>
>>>>>>> This whole problem did not need to happen. When the federation spec
>>>>>>> was being created I asked them not to deviate unnecessarily from pki. But
>>>>>>> the very guys that are on this thread told me that they were not a pki and
>>>>>>> so there was no reason for them to follow existing rules. This is entirely
>>>>>>> a problem of there own making. So let them fix their own mistakes.
>>>>>>>
>>>>>>> thx ..Tom (mobile)
>>>>>>>
>>>>>>> On Mon, Jun 10, 2024, 8:37 PM Watson Ladd <watsonbladd@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
>>>>>>>> <michael_b_jones@hotmail.com> wrote:
>>>>>>>> >
>>>>>>>> > We all know that TLS certificates are handled by platform layers
>>>>>>>> used by applications and not the applications themselves.  There is no code
>>>>>>>> that understands X.509 certificates in most applications that use TLS.
>>>>>>>> They are not equivalent in complexity.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > The draft would require adding code directly understanding the
>>>>>>>> structure and fields of X.509 to applications using it.  Eliminate that,
>>>>>>>> and I’ll support adoption.
>>>>>>>>
>>>>>>>> I don't understand your proposal. An X509 certificate is the only
>>>>>>>> way
>>>>>>>> to link a DNS name to a key at a given point in time as we can
>>>>>>>> leverage the Web PKI. Absent that, what do you do?
>>>>>>>>
>>>>>>>> Also, I'm not sure what you mean by platform layers. Many of them
>>>>>>>> expose a function to verify a signature with a key in an X509 cert
>>>>>>>> or
>>>>>>>> verify a cert chain, even outside the context of TLS. Are there
>>>>>>>> particular ones that would have a problem you are concerned about?
>>>>>>>>
>>>>>>>> Sincerely,
>>>>>>>> Watson Ladd
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list -- oauth@ietf.org
>>>>>>>> To unsubscribe send an email to oauth-leave@ietf.org
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list -- oauth@ietf.org
>>>>>>> To unsubscribe send an email to oauth-leave@ietf.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list -- oauth@ietf.org
>>>>>> To unsubscribe send an email to oauth-leave@ietf.org
>>>>>>
>>>>>