Re: [Id-event] Push Delivery: working group last call
John Bradley <ve7jtb@ve7jtb.com> Wed, 27 March 2019 08:34 UTC
Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2C4120278 for <id-event@ietfa.amsl.com>; Wed, 27 Mar 2019 01:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ve7jtb-com.20150623.gappssmtp.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 qkIkOpGS2v0u for <id-event@ietfa.amsl.com>; Wed, 27 Mar 2019 01:34:54 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 DD46F120273 for <id-event@ietf.org>; Wed, 27 Mar 2019 01:34:53 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id q16so15225252wmj.3 for <id-event@ietf.org>; Wed, 27 Mar 2019 01:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KUs4PFHV4Z/zNTflrRxBkL8wr1hayZM/7hP4pySmww0=; b=nnxqhYIGNddiwbiIOziMkfi/FGhpgUpGr4gWLDEf8TJjlPXNPMtDKTBZyqBDb/fF1n WU601dcef0dFEgvuM+odqPDUSTqo5mRKTrR6t0wcRNkeSPwhYIXSJYxBbc7V1pVeuN8d N7dcrU30CTznK05ssBV+HuzRFR/QUpauFzpWVb8IBa2Z3SodHHN45ocgKl0SZ3wd3Nbt z0fe9043VnBp+wZ4X6BGCYrj+rg8l5abYSlEzwqYb3gxOaVAnarWe5Nut8pbysPiFC+W df9POovIJschvaSOxpKpEPqO9fe6KfKxbcZx7zy3UXthmEgtr12HBeI7im5cAn1+WIBO nO+Q==
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=KUs4PFHV4Z/zNTflrRxBkL8wr1hayZM/7hP4pySmww0=; b=Kx98c+EaBwvEESSAAMnrubqZj6KnbUFae3b1gQ6uuQVhNhh2kNtEtV5M4CaLMI9pZS X5g3uVR1Y3azWT9s207X1nU6sd2t8CatuGLmLaTJz4q0iTPAanGD9J7xkMrIn4xZMYPw rM921uTD7CEAeIcQ5yNpUOW43qqDtklOo16ST0aMNWDuYOisIO2U3ZQ0Bt0wDLzR+Ica GrfJcxUU+mIoNVg/5V/l3rzOl1APPk71e4AniRP2Y8TemCK7K1cdl8XAwyrNRxJ4f5sc wa0toHGX8U3fe4Em7gYQOGELIDVAjn2gZRT18FaoWjC6PqNOhHufrk7owFv7cb0IuMcH kazQ==
X-Gm-Message-State: APjAAAVLacR1SdMOPNr3fFTFUSOUohga9FJophwlz+PYh4ZiQptBdBgM mgFWjIGfs0jIApBSa77NBfdSiRmZZlYB+BA+ixGaNA==
X-Google-Smtp-Source: APXvYqyvWbIQ3xy8fbxqRa5FEFHPkUYAUhrQ6AU65jvj4DtW+CmiKObFybTnQ6VbCIzM9sqAAqSYgrexYiRJd0uULFo=
X-Received: by 2002:a1c:2d91:: with SMTP id t139mr18623517wmt.102.1553675691764; Wed, 27 Mar 2019 01:34:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-t0eteREXoE6HD4ZUKw7G-P=WAtM1ksPuQEu_5oU=hPuA@mail.gmail.com> <c619b0bb-9322-55a5-8a26-566d2230518a@gmail.com> <4C82F80F-74ED-4EA0-AE47-0A4D8DB40A43@amazon.com> <933153f4-e3a2-73ba-3165-6f1ebd28f4d7@gmail.com> <CABpvcNuL=MFahqFi0dXm5TEeNXedKL3AUsbws6EkA0p=s4Y82g@mail.gmail.com>
In-Reply-To: <CABpvcNuL=MFahqFi0dXm5TEeNXedKL3AUsbws6EkA0p=s4Y82g@mail.gmail.com>
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Wed, 27 Mar 2019 09:34:39 +0100
Message-ID: <CAANoGh+LtpxzZk4GVi5aa4iVNu8V12p=JSJ0aarb8TY1pOnp4w@mail.gmail.com>
To: Marius Scurtescu <marius.scurtescu=40coinbase.com@dmarc.ietf.org>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Anthony Nadalin <tonynad@microsoft.com>, "Richard Backman, Annabelle" <richanna@amazon.com>, "Morteza Ansari (moransar)" <moransar@cisco.com>, Mike Jones <Michael.Jones@microsoft.com>, Marius Scurtescu <marius.scurtescu@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, SecEvent <id-event@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b443a405850f4fbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/X2WdwplxdfwPfD42bzDP3SXOVYQ>
X-Mailman-Approved-At: Wed, 27 Mar 2019 08:38:54 -0700
Subject: Re: [Id-event] Push Delivery: working group last call
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 08:34:57 -0000
+1 On Mon, Feb 4, 2019, 7:43 PM Marius Scurtescu <marius.scurtescu= 40coinbase.com@dmarc.ietf.org> wrote: > I support the publication of this document, with the changes suggested by > Yaron Shefer and Annabelle Richard Backman.. > > On Fri, Jan 25, 2019 at 1:04 PM Yaron Sheffer <yaronf.ietf@gmail.com> > wrote: > >> Thanks for the quick response! A few comments inline. >> >> On 25/01/2019 22:18, Richard Backman, Annabelle wrote: >> > Thanks for the feedback! Responses inline. >> > >> > -- >> > >> > Annabelle Richard Backman >> > >> > AWS Identity >> > >> > On 1/25/19, 9:59 AM, "Id-event on behalf of Yaron Sheffer" >> > <id-event-bounces@ietf.org on behalf of yaronf.ietf@gmail.com >> <yaronf.ietf@gmail..com>> wrote: >> > >> > The document looks good. Here's a bunch o' comments. >> > >> > * Intro: receipt->recipient >> > >> > [richanna]👍[/richanna] >> > >> > * "The transmitter and recipient are known to one another." But >> > then we >> > >> > require the *issuer* to be authenticated by the Recipient. We need >> to >> > >> > clarify the relationship between Issuer (defined in the base spec) >> and >> > >> > Transmitter. BTW, Issuer should be capitalized. >> > >> > [richanna] >> > >> > The intent of that sentence is to indicate that the spec assumes the >> > Transmitter already knows who it needs to transmit the SET to, and the >> > Recipient knows who it expects to receive SETs from, and that discovery >> > of either is out of scope. >> > >> > You’re absolutely right. Section 2 is missing a validation step: “The >> > SET Recipient is willing to accept the SET, when transmitted by the SET >> > Transmitter.” Also, we can add text to the definition of SET >> Transmitter >> > to clarify that it need not be the Issuer of the SET. >> > >> > [/richanna] >> > >> > * "a decryption failure that may be due to misconfigured keys" - >> > this is >> > >> > a strange reason for retransmission, because it would normally >> > require a >> > >> > very slow manual operation, which could easily overwhelm the >> > Transmitter. >> > >> > [richanna] >> > >> > I had in mind issues or delays with key propagation after a rotation, >> > premature rejection of an outgoing key due to clock skew, intermittent >> > failure when retrieving a Transmitter’s public key, etc. These are >> > issues that may (depending on root cause) work themselves out after a >> > few minutes, though I suppose they are not properly “misconfigured >> > keys.” This example is probably just muddying the waters without >> > contributing much to the text. >> > >> > [/richanna] >> > >> > * "Transmitting a SET": if the normal response has an empty body, >> > why do >> > >> > we send "Accept: application/json"? The Accept header is not >> > mandatory, >> > >> > https://tools.ietf.org/html/rfc7231#section-5.3.2 >> > >> > [richanna] >> > >> > Error responses will contain a JSON-formatted body, which the >> > Transmitter MUST be prepared to accept. >> > >> > [/richanna] >> >> YS: I still think the Accept header is redundant (in particular because >> if you cannot understand JSON, you cannot use this protocol at all), but >> I can live with it. >> >> > >> > * "Failure Response": why is responding with the right HTTP status >> > code >> > >> > a MAY? What else do we expect them to do? >> > >> > [richanna] >> > >> > As I understand it, HTTP Servers have some discretion with regards to >> > which status codes they respond with in certain situations. The “right >> > HTTP status code” can be subjective, and may change over time as new >> > status codes are defined for specific cases. SET Transmitters need to >> be >> > prepared to receive standard HTTP status codes, but I don’t see a >> reason >> > to impose more requirements on the SET Recipient in this area than HTTP >> > itself does. >> > >> > [/richanna] >> > >> >> YS: I agree with everything you say, but still, this would be more >> correct: "the SET Recipient SHOULD respond with an appropriate HTTP >> Status Code", even if the "appropriate" code is very fuzzy. Or else, >> let's remove the RFC 2119 word: "the Recipient responds". >> >> > * "the SET Transmitter is not permitted to transmit SETs issued by >> the >> > >> > issuer specified in the SET" - I suggest to change the text to >> > indicate >> > >> > this is from the point of view of the Recipient: "the Recipient is >> not >> > >> > willing to accept SETs issued by the specified issuer from this >> > >> > particular SET Transmitter". >> > >> > [richanna]👍[/richanna] >> > >> > * Error codes: what if the Recipient expects the SET to be >> protected >> > >> > (e.g. signed) but it is not? Is this "authentication_failed"? >> > >> > [richanna] >> > >> > SET signatures authenticate the Issuer, not the Transmitter, so >> > `authentication_failed` would be inappropriate. The Recipient should >> > return `access_denied` as it is unwilling to accept this SET from this >> > Transmitter. Now I’m actually wondering if there is a difference >> between >> > `invalid_request` and `access_denied` that is meaningful at runtime. >> > I’ll start a thread on this. >> > >> > [/richanna] >> > >> > * "MUST support TLS 1.2" - we should allow for a future where TLS >> > >> > 1.3-only is acceptable. So, "MUST support TLS 1.2 or later". >> > >> > [richanna]👍[/richanna] >> > >> > * IANA: the Expert Review policy requires a designated expert, >> > >> > obviously. Since this is the only SecEvent registry that needs it >> so >> > >> > far, I'd rather go for the simpler FCFS policy. >> > >> > [richanna] >> > >> > 👍, though I think we should add text to the effect of “Error Codes are >> > intended to be interpreted by automated systems, and therefore SHOULD >> > identify classes of errors in response to which an automated system >> > could take some distinct action.” >> > >> > [/richanna] >> >> YS: guidance is always good. >> >> > >> > Thanks, >> > >> > Yaron >> > >> > On 24/01/2019 20:11, Dick Hardt wrote: >> > >> > > Dear SecEvent participants, >> > >> > > >> > >> > > This is to start a 2-week working group last call >> > >> > > on draft-ietf-secevent-http-push-04 >> > >> > > >> > >> > > https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/ >> <https://datatracker.ietf..org/doc/draft-ietf-secevent-http-push/> >> > >> > > >> > >> > > until Feb 8, 2019. >> > >> > > >> > >> > > Please send any comments to the list. In addition, if you have no >> > >> > > comments but support publication of this document as-is, please >> > >> > > make your voice heard. >> > >> > > >> > >> > > Thanks, >> > >> > > >> > >> > > Dick and Yaron >> > >> > _______________________________________________ >> > >> > Id-event mailing list >> > >> > Id-event@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/id-event >> > >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event >
- [Id-event] Push Delivery: working group last call Dick Hardt
- Re: [Id-event] Push Delivery: working group last … Yaron Sheffer
- Re: [Id-event] Push Delivery: working group last … Richard Backman, Annabelle
- Re: [Id-event] Push Delivery: working group last … Marius Scurtescu
- Re: [Id-event] Push Delivery: working group last … Yaron Sheffer
- Re: [Id-event] Push Delivery: working group last … Marius Scurtescu
- Re: [Id-event] Push Delivery: working group last … Phil Hunt
- Re: [Id-event] Push Delivery: working group last … Morteza Ansari (moransar)
- Re: [Id-event] Push Delivery: working group last … Dick Hardt
- Re: [Id-event] Push Delivery: working group last … Luke Camery
- Re: [Id-event] Push Delivery: working group last … Adam Dawes
- Re: [Id-event] Push Delivery: working group last … Adam Dawes
- Re: [Id-event] Push Delivery: working group last … Dick Hardt
- Re: [Id-event] Push Delivery: working group last … Richard Backman, Annabelle
- Re: [Id-event] Push Delivery: working group last … Dick Hardt
- Re: [Id-event] Push Delivery: working group last … Richard Backman, Annabelle
- Re: [Id-event] Push Delivery: working group last … Mike Jones
- Re: [Id-event] Push Delivery: working group last … Mike Jones
- Re: [Id-event] Push Delivery: working group last … John Bradley