Subject: Re: [Anima] draft-richardson-anima-ace-constrained-voucher

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Jun 2018 11:55:05 -0400

{clearing out old emails}

Jim Schaad <[email-masked]> wrote:
    > There are a couple of questions that I would put here that I think guides
    > things.

    > *  Is there any expectation that the path components would ever change for
    > some implementation or are they always going to be the same?  Would a
    > request voucher always be posted to /rv or could an implementation change it
    > to be /rvr?

To me, there is no reason.

    > *  Is there a reason for an endpoint to want to get what services are
    > supported as a general rule rather than just assuming that if the root
    > exists then all of the services are also going to exist.

I would tend to think that was the case.

    > If the answer to the first question is no, then I don't know that they even
    > need to have resource types.  You get the root and go from there.

    > If the answer to both questions is yes, then a different rt for every
    > service would be needed so that they can be distinguished.

    > If the answer to the first question is no and the second is yes, then it
    > would make sense to define a generic rt='ace.est.service' so that the root
    > and the list of services can be queried for individually.

I don't think it's justified.

It might be useful to be able to inquire to an EST (CoAP) end point whether or not
it supports the BRSKI extensions, but I can't come up with an operational
situation where this would be used.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Jun 2018 13:56:25 -0400

Jim, in the situation where a COSE/CBOR voucher has been signed by a Raw
Public Key (whether ECDSA or EdDSA), and the signing (public) key needs to be
transfered, would you recommend:

1) use RFC8152, section 7.1 to describe the key.
   Same as you use in your Examples git tree.
   What MIME-TYPE would you use to transfer such a thing?

2) use (Subject-)Public-Key-Info encoded
   as specified in RFC7250, section 3.
   What MIME-TYPE would you use to transfer such a thing?

---

From: Jim Schaad <[email-masked]>
Date: Fri, 15 Jun 2018 11:21:00 -0700

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: Friday, June 15, 2018 10:56 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: sending raw public key over the wire
> 
> 
> Public Key (whether ECDSA or EdDSA), and the signing (public) key needs to
> be transfered, would you recommend:
> 

Per RFC8152 section 16.9.2 - application/cose-key or
application/cose-key-set depending on which of the COSE key structure that
are to be used.

>    What MIME-TYPE would you use to transfer such a thing?

The RPK is transferred as part of the DTLS negotiation.  As such it is
transferred, but not trusted in DTLS.  If you do FUD then that is
sufficient.  If it is not sufficient then you could use the answer to 1 as
one of many different ways to transfer keys.  Keys can be transferred as
COSE_Keys, JOSE_keys, PEMs or Certificates each of which defines a
Media-Type.   Of course the PRK could also be baked into the device as well.

Jim