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

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Sep 2020 15:52:42 -0400

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 17 Sep 2020 18:21:56 +0000

Hi Michael,

Sorry for the late replay on this. There is probably one fits all answer for this. The reason is that the enrollment protocols are defined different in that respect. 
- EST does not provide it out of the box, this was the reason to have it in BRSKI
- CMP provides a certificate confirmation message (certConf).
- CMC provides a confirmation message with the Confirm Certificate Acceptance Control
- SCEP explicitly mentions the lack of the certificate confirmation message in the security consideration section
- ACME seems to not provide it either. 

Given that it would make sense to move it to /brski to make it independent from EST. 
Contrary, BRSKI-AE that would benefit from the /est to /brski change by making the enrollment protocol choice independent form the voucher exchange builds on authenticated self-contained objects (signature wrapped objects). These are currently supported by EST with fullcmc, CMP, and CMC. SCEP from my understanding does not support enrollment using a certificate from a different issuing CA. It supports reenrollment  using the existing certificate but not initial enrollment as the IDevID would be issued from a different CA. That was at least my understanding by reading section 2.3 of SCEP. 
Based on the assumption that CMP and CMC provide the signature wrapping without limitations and also support certificate confirmation messages, it seems to be only applicable to EST (simpleenroll or fullcmc). That would rather indicate to keep "/.well-known/est/enrollstatus" as is. 

Best regards
Steffen

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> Sent: Mittwoch, 16. September 2020 21:53
> To: [email-masked]
> Subject: [Anima] about moving /.well-known/est/enrollstatus ??
> 
> 
> One of the changes in the diff that I thought I had raised, but got no discussion
> was enrollstatus.
> 
> 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.
> 
> As such, it is unclear to me if this is tied up in EST only, or whether this is really a
> BRSKI thing.
> 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 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.
> 
> --

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 18 Sep 2020 06:27:23 +0000

> Sorry for the late replay on this. There is probably one fits all answer for this.
I definitely meant no single answer to this.

> The reason is that the enrollment protocols are defined different in that
> respect.
> Contrary, BRSKI-AE that would benefit from the /est to /brski change by
> making the enrollment protocol choice independent form the voucher
> exchange builds on authenticated self-contained objects (signature wrapped
> objects). These are currently supported by EST with fullcmc, CMP, and CMC.
> SCEP from my understanding does not support enrollment using a certificate
> from a different issuing CA. It supports reenrollment  using the existing
> certificate but not initial enrollment as the IDevID would be issued from a
> different CA. That was at least my understanding by reading section 2.3 of
> SCEP.
> Based on the assumption that CMP and CMC provide the signature wrapping
> without limitations and also support certificate confirmation messages, it
> seems to be only applicable to EST (simpleenroll or fullcmc). That would
> rather indicate to keep "/.well-known/est/enrollstatus" as is.
After thinking twice about it and also rereading section 5.9.4 of BRSKI, I would suggest to also move enrollstatus to "/.well-known/brski/enrollstatus".
The reason for this is the following: 
- enrollstatus has been introduced to inform the registrar that the pledge confirms it has received the certificate and can use it.
- as stated in section 5.9.4 of BRSKI, enrollstatus can also be used to signal " attempted bootstrapping messages seen by the client". This is definitely an additional information not covered in existing certificate confirmation messages that the client at least tried enrollment but may not have been successful.
- The certificate confirmation messages defined in protocols like CMP and CMC are intended to also inform the CA, which would mean it is a message further forwarded by the registrar. This also means that additional information for the registrar, e.g., about enrollment attempts may not be contained in these messages.

Based on that the enrollstatus provides a value to the registrar independent of the enrollment protocol chosen. 

Best regards
Steffen

> > The first is the /.well-known/est/voucher_status. This is a report on
> > whether the voucher was acceptable.  This is entirely RFC8366/BRSKI
> > 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 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.
> >
> > --

---

From: Esko Dijk <[email-masked]>
Date: Fri, 18 Sep 2020 12:02:58 +0000

Agree with moving the enrollstatus into the ".well-known/brski" domain. If the EST enrollment (which is a SHOULD as part of BRSKI, so a client might in principle use another protocol) fails for example then the failure to enroll would logically be reported back in the BRSKI context. 

Note: There are some issues in the current payload definition in BRSKI voucher status and enrollment status, I've created 
https://github.com/anima-wg/anima-bootstrap/issues/144
for these.

Is any help needed to author these updates? (Or does this need to be taken up in the errata once we publish as RFC...? I remember that people want to rather have it published than polished.)

Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Fries, Steffen
Sent: Friday, September 18, 2020 08:27
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Anima] about moving /.well-known/est/enrollstatus ??

Best regards
Steffen

> > something that is unimplementable.

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 17:33:44 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    max> Aside, but can post to the list if you want.

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

    max> An argument that s5.7 voucher_status should be at BRSKI well-known could be made.

    max> I’ve always thought of this as an extension of EST but the language
    max> has changed. See 2nd to last paragraph of s1 and all of section 5.9
    max> as discussions of the integration. In particular though s5 states: 

    doc> BRSKI is described as extensions to EST
    doc> [RFC7030]. The
    doc> goal of these extensions is to reduce the number of TLS connections
    doc> and crypto operations required on the pledge. The registrar
    doc> implements the BRSKI REST interface within the same "/.well-known"
    doc> URI tree as the existing EST URIs as described in EST
    doc> [RFC7030]
    doc> section 3.2.2. The communication channel between the pledge and the
    doc> registrar is referred to as "BRSKI-EST" (see Figure
    doc> 1). 

    max> So are you proposing to shift a bunch over?

The question is about the enrollment_status only.

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

    max> This feels more like a perspective and pedant discussion. If folks
    max> are particularly pedantic or feel that BRSKI is distinct from EST
    max> then put them in distinct well-known locations. Or if folks agree
    max> they’re closely linked and might be implemented using the same
    max> server’s then put them at the same location.

I want to point out that implementing any of the things on very much separate
servers is very problematic.  The authorization for the enrollment operation
(whether EST or anything) is essentially dependant on the successful voucher
operation.  When the Registrar sends a successful voucher to the pledge, it
essentially has to bless that TLS connection.

    max> I think its that implementation question that might matter the most?
    max> But since there is a focus on re-using the TLS connection it would
    max> feel weird to me to have distinct processes; which means closely
    max> integrated implementation which means this isn’t an implementation
    max> problem. Methinks. 

Eliot has mentioned questions about Flask, or Rails, or other frameworks
ability to deal with different URL paths.  Maybe there are some where it's an
issue, in which case, I'd say that they are probably broken in more profound
ways.   I have not encountered a framework where it matters.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 17:34:38 -0400

Fries, Steffen <[email-masked]> wrote:
    > Sorry for the late replay on this. There is probably one fits all
    > answer for this. The reason is that the enrollment protocols are
    > defined different in that respect.  
    > - SCEP explicitly mentions the lack of the certificate confirmation
    > message in the security consideration section 

    > Given that it would make sense to move it to /brski to make it

Interesting.
So when doing CMP or CMC, would there be two confirmations?

    > without limitations and also support certificate confirmation messages,
    > it seems to be only applicable to EST (simpleenroll or fullcmc). That
    > would rather indicate to keep "/.well-known/est/enrollstatus" as is.

okay.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 17:39:32 -0400

> After thinking twice about it and also rereading section 5.9.4 of
    > BRSKI, I would suggest to also move enrollstatus to
    > "/.well-known/brski/enrollstatus".

haha. I see that I now actually mis-read your first email to mean the
second one.

    > - as stated in section 5.9.4 of BRSKI, enrollstatus can also be used =
to
    > signal " attempted bootstrapping messages seen by the client". This is
    > definitely an additional information not covered in existing
    > certificate confirmation messages that the client at least tried
    > enrollment but may not have been successful.

yes, that is where we cared.
We knew that if it failed, that we'd want as much information as possible r=
eturned.

If a truck roll is required (in a DC/ISP situation), the information in the
failure message would be important in deciding if it was junior remote-hands
that would just power the system to try again, or if someone more senior
needs to go.=20

    > - The certificate confirmation messages defined in protocols like CMP
    > and CMC are intended to also inform the CA, which would mean it is a
    > message further forwarded by the registrar. This also means that
    > additional information for the registrar, e.g., about enrollment
    > attempts may not be contained in these messages.

The enrollment_status message could be extended to include CMP information.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 17:44:18 -0400

> https://github.com/anima-wg/anima-bootstrap/issues/144

I think that the "1" -> 1, can be fixed in AUTH48.
   https://github.com/anima-wg/anima-bootstrap/commit/0830f26eee796624f40e0a0387933e608ebee063

You also complain about successful should not have reasons.
That seems like a bigger change, and am not sure it matters.
I thought that we have CDDL for both telemetry. 

    > Is any help needed to author these updates? (Or does this need to be
    > taken up in the errata once we publish as RFC...? I remember that
    > people want to rather have it published than polished.)

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 21 Sep 2020 06:40:30 +0000

> Von: Anima <[email-masked]> Im Auftrag von Michael Richardson
> 

CMP has a certConf message, but it can be omitted where BRSKI is carrying the content in enrollstatus.

---

From: Esko Dijk <[email-masked]>
Date: Mon, 21 Sep 2020 09:28:22 +0000

The draft -43 Section 5.7 (Voucher status telemetry) does not have a CDDL description, nor a reference to it.  (Am I looking at the right version?)

In Section 5.9.4  in the CDDL (Fig 18) , was the "reason" field intended to be optional ?  It is currently not optional but mandatory so the reason field then must be present also in success cases. In this case please ignore my comment that the example (Fig 19) has the 'reason' field.

What is confusing is that in Section 5.7 the reason field looks OPTIONAL for the voucher status telemetry.  (Text: " The version and status fields MUST be present.  The Reason field SHOULD be present whenever the status field is false." )
Why not have the same / similar CDDL for Section 5.7 and thus make the Reason field mandatory? That would avoid needless variation here and reduce future confusion of implementers.  

Could you please reopen issue #144 ? ( It looks like I can't do that.)  Not all the issues we're discussing are currently addressed by the Github commit.

Esko

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Sep 2020 12:28:54 -0400

Esko Dijk <[email-masked]> wrote:
    > The draft -43 Section 5.7 (Voucher status telemetry) does not have a
    > CDDL description, nor a reference to it.  (Am I looking at the right
    > version?)

Yes.
I'm about to post -44 which arguably, I should have done after WGLC to rename,
and before IETF LC.   I include CDDL for the voucher status.

    > In Section 5.9.4  in the CDDL (Fig 18) , was the "reason" field
    > intended to be optional ?  It is currently not optional but mandatory
    > so the reason field then must be present also in success cases. In this
    > case please ignore my comment that the example (Fig 19) has the
    > 'reason' field.

You are suggesting that "reason" should be optional.
My code puts something into reason in the success case, but I agree that it
does not need to be there.

    > What is confusing is that in Section 5.7 the reason field looks
    > OPTIONAL for the voucher status telemetry.  (Text: " The version and
    > status fields MUST be present.  The Reason field SHOULD be present
    > whenever the status field is false." )

    > Why not have the same / similar CDDL for Section 5.7 and thus make the
    > Reason field mandatory? That would avoid needless variation here and
    > reduce future confusion of implementers.

Do you mean the enrollstatus should be identical wording to the voucher
status, which says:
   "In the case of a SUCCESS the Reason string is omitted."

I agree that they should be consistent.
So would you like me to write:
   The version and status fields MUST be present.  The Reason field SHOULD be present
   whenever the status field is false.
   In the case of a SUCCESS the Reason string MAY be omitted.

This will require an AD blessing, officially.

    > Could you please reopen issue #144 ? ( It looks like I can't do that.)
    > Not all the issues we're discussing are currently addressed by the
    > Github commit.

I've done that.