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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Monday, April 30, 2018 12:18 PM
> To: [e-mail]; Jim Schaad <[e-mail]>
> Cc: [e-mail]
> Subject: Re: draft-richardson-anima-ace-constrained-voucher
> 
> 
> peter van der Stok <[e-mail]> wrote:
>     >> * Section 5 - you have a return of multiple items with the same rt
value.
>     >> However I would not want to have to filter through the list of
return
>     >> values
>     >> to figure out which is the "root" one.  Should this example have
the
>     >> rt=ace.est attribute on all of the links?
> 
>     > The example is an example and people can decide to do it
differently.
>     > Two alternatives:
>     > - only return the root collection
>     > - define additional rt values per resource
>     >
>     > You have a preference? I prefer the first approach
> 
> I'm not clueful about this part, and generally quite fearful about parsing
this
> stuff.  Sure, it's easy in Ruby, but it's the constrained C code that I'm
> concerned about, so I don't understand the tradeoffs here.

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? 
*  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.  

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.

> 
>     jim> * Suggest a strong recommendation on not use cmsVersion=1 to
> make your life
>     jim> easier.
> 
> In other words: to not be PKCS7 compatible, but require CMS processing.
> 
> I think this is reasonable from a specification point of view, but there
has
> been pushback from people who have FIPS-140 libraries that they have hard
> times getting updated.

Just to be clear, they have updated the library sufficiently to be able to
verify CMS messages but not to create them?  We are also talking about
libraries which have not been updated to deal with any 'new' crypto as that
would not be supported by old bcrypt libraries as well.

Note this is also an interesting question for how you are going to label the
CBOR encoded voucher.  If you use id-data, then the question is moot and
everybody goes forward happy.  On the other hand if you assign a new OID for
this then it would need to be an ASN.1 object for the PKCKS7 people to
encode based on my historic work with such packages.  This is because for
types which are not id-data the type and length bytes are stripped from the
content before it is processed by the PKCS#7 library.  

Jim


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