Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices

From: Esko Dijk <[email-masked]>
Date: Wed, 23 Jan 2019 09:48:40 +0000

Dear ACE WG & authors,

My main comment on this draft is based on recent experience with an embedded implementation. In the draft, the content format "application/pkcs7-mime;smime-type=certs-only" is used to transport a single certificate back to the client. However, in the embedded implementation crypto library there is no support for parsing this format, but there is support for parsing X.509v3 (application/pkix-cert). See e.g. https://tls.mbed.org/api/group__x509__module.html for an embedded API that can parse CSR and certs, but not PKCS#7.

Therefore the X.509 format seems better to use; also given that 
1) the signing of data that the PKCS#7 S/MIME envelope provides is useless because the DTLS session is already end-to-end protected and the certificate is already signed; and 
2) RFC 7030 requires that only one certificate, the  generated one, is carried in the /simple(re)enroll response so that a container format for multiple certificates is not really needed here.

So to reduce code size for embedded implementations it would be very beneficial if the EST Server would support an additional content format:
application/pkix-cert  (see RFC 5280)

The client can request this format using the CoAP Accept Option; by default if no Accept Option given the EST server would return application/pkcs7-mime;smime-type=certs-only.
What do you think about this addition? I believe that adding this would make the EST-over-Coaps protocol an ideal fit to common embedded SW stacks.

Furthmore I found these two issues that need to be addressed:

Section 5.4: "The equivalent CoAP error code to use in an EST-coaps responses are 2.04 ..." -> 2.04 is a success code, not an error.

Section 5.6: "According to section 5.2.2 of [RFC7252], a slow server can acknowledge the request with a 2.31 code" -> 2.31 is not specified in RFC 7252.

Best regards
Esko Dijk

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, January 14, 2019 05:03
To: [email-masked]
Subject: [Ace] WGLC for draft-ietf-ace-coap-est

The chairs believe that the EST over CoAP draft is nearing the point it should be sent to the IESG for publication.  We are therefore going to have a Working Group Last Call on this document.  WGLC will until 29th of this month.  Please review the document and send comments both positive and negative to the list about its state.

Jim & Roman

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jan 2019 21:26:47 -0500

Esko Dijk <[email-masked]> wrote:
    > My main comment on this draft is based on recent experience with an
    > embedded implementation. In the draft, the content format
    > "application/pkcs7-mime;smime-type=certs-only" is used to transport a
    > single certificate back to the client. However, in the embedded
    > implementation crypto library there is no support for parsing this
    > format, but there is support for parsing X.509v3
    > (application/pkix-cert). See
    > e.g. https://tls.mbed.org/api/group__x509__module.html for an embedded
    > API that can parse CSR and certs, but not PKCS#7.

    > 2) RFC 7030 requires that only one certificate, the  generated one, is
    > carried in the /simple(re)enroll response so that a container format
    > for multiple certificates is not really needed here.

    > So to reduce code size for embedded implementations it would be very
    > beneficial if the EST Server would support an additional content
    > format:

I think that this is a reasonable thing to do.
The client can easily say what it wants and I think the two formats are
relatively easy to swap.

What about if we went further, and went to:
             Concise Identities
             draft-birkholz-core-coid-01

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 23 Jan 2019 21:05:19 -0800

> From: Ace <[email-masked]> On Behalf Of Michael Richardson
> Sent: Wednesday, January 23, 2019 6:27 PM
> To: Esko Dijk <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for
> embedded devices
> 
> 
>     > 1) the signing of data that the PKCS#7 S/MIME envelope provides is
> useless because the DTLS session is already end-to-end protected and the
> certificate is already signed; and

There is no signature for this CMS signed message format.  It only contains
the certificates and CRLs that are passed back.  I would still think that
this is a fine idea as long as you are only going to return the leaf
certificate and not returning a bag of certificates or any CRLs.

>              draft-birkholz-core-coid-01

Given that it would be a blocking factor, I would think about this as maybe
something in the future.

Jim

---

From: Esko Dijk <[email-masked]>
Date: Thu, 24 Jan 2019 08:45:06 +0000

> There is no signature for this CMS signed message format.  It only contains the certificates and CRLs that are passed back.  I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs.

That's right, only the leaf certificate is returned and no CRLs; in this embedded case. Any other required certificates are already obtained from the prior DTLS handshake process.
I agree that using draft-birkholz-core-coid-01 could be used in the future as an alternative format instead of an X.509 certificate. Ideally, it would become an update of RFC-EST-over-coaps and an enrolling client can indicate it uses the new formats by using e.g. CoAP Content-Format and Accept Options, or by different URI paths. 

Best regards
Esko

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Thursday, January 24, 2019 06:05
To: 'Michael Richardson' <[email-masked]>; Esko Dijk <[email-masked]>
Cc: [email-masked]
Subject: RE: [Ace] WGLC for draft-ietf-ace-coap-est - optimization for embedded devices

>     > "application/pkcs7-mime;smime-type=certs-only" is used to 
> transport
a
>     > 1) the signing of data that the PKCS#7 S/MIME envelope provides 
> is useless because the DTLS session is already end-to-end protected 
> and the certificate is already signed; and

There is no signature for this CMS signed message format.  It only contains the certificates and CRLs that are passed back.  I would still think that this is a fine idea as long as you are only going to return the leaf certificate and not returning a bag of certificates or any CRLs.

>     > 2) RFC 7030 requires that only one certificate, the  generated 
> one,
is
> The client can easily say what it wants and I think the two formats 
> are relatively easy to swap.
> 

Given that it would be a blocking factor, I would think about this as maybe something in the future.

Jim

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jan 2019 11:01:01 -0500

> application/pkix-cert  (see RFC 5280)

So, to implement this in the specification, we need an additional
Content-Type value to be allocated.

If we have WG Consensus to add this, then we can spin the document and ask
for another early allocation.

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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 24 Jan 2019 18:32:24 -0800

As ACE co-chair,

Of anybody on the mailing list believes that the document should not add a
new CoAP content type for "application/pkix-cert" please speak up before
next Monday.

Jim

> Sent: Thursday, January 24, 2019 8:01 AM
> So, to implement this in the specification, we need an additional Content-
> Type value to be allocated.
> 
> If we have WG Consensus to add this, then we can spin the document and
> ask for another early allocation.
> 
> --