[Anima] about moving /.well-known/est/enrollstatus ??

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 September 2020 19:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C99083A0C02 for <anima@ietfa.amsl.com>; Wed, 16 Sep 2020 12:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JYZ6v8xpCvkj for <anima@ietfa.amsl.com>; Wed, 16 Sep 2020 12:52:45 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAA53A0BFC for <anima@ietf.org>; Wed, 16 Sep 2020 12:52:45 -0700 (PDT)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id 09ACA389A9 for <anima@ietf.org>; Wed, 16 Sep 2020 15:31:27 -0400 (EDT)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id U-sQsZys28U7 for <anima@ietf.org>; Wed, 16 Sep 2020 15:31:26 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 96F4B389A3 for <anima@ietf.org>; Wed, 16 Sep 2020 15:31:25 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 298A94F5 for <anima@ietf.org>; Wed, 16 Sep 2020 15:52:42 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 16 Sep 2020 15:52:42 -0400
Message-ID: <16833.1600285962@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/MUDN0BUdkn0QssUvpDSVqClRu3c>
Subject: [Anima] about moving /.well-known/est/enrollstatus ??
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 19:52:50 -0000

One of the changes in the diff that I thought I had raised, but got no
discussion was enrollstatus.

There are two telemetry status reports that BRSKI added .. "to EST".
The first is the /.well-known/est/voucher_status. This is a report
on whether the voucher was acceptable.  This is entirely RFC8366/BRSKI
content, and is completely independant of the certificate enrollment
protocol.  It should change to /.well-known/brski/voucher_status.

The second one, described in section 5.9.4 is about whether or not the
certificate was enrolled correctly.   This provides feedback about whether or
not the new certificate was retrieved and installed correctly.

It says to use the new certificate and report.
It's not that interesting when there is success.

It's more interesting when there is a failure of some kind.
As such, it is unclear to me if this is tied up in EST only, or
whether this is really a BRSKI thing.
It's not BRSKI/RFC8366 that failed, it's EST/CMP/SCEP/pixie-dust that failed.

It seems that moving it to /brski is acceptable, but it might be that
it should remain in /est.  I am not steeped in the art of CMP or SCEP or ???,
so I don't know if what we've done for EST will translate well.

I do not feel strongly either way, but in the diff I left a ?XXX because I didn't know.
I am sorry to bring this up during the IETF last-call: I think that I just
need some confirmation from CMP experts that we aren't creating something
that is unimplementable.

Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide