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

From: Jim Schaad <[email-masked]>
Date: Fri, 27 Apr 2018 14:24:38 -0700

A fast review of the document, but I have no problems with having it
adopted.

* In section 1 para #4 you appear to have a formatting error where a list
was supposed to exist.

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

*  Section 5  the description of ct=16 is not quite correct as it is missing
the encrypt0 subtype.  This text might lead people to conclude that any
application/cose type can use 16

* Suggest a strong recommendation on not use cmsVersion=1 to make your life
easier.

Jim

---

From: peter van der Stok <[email-masked]>
Date: Sat, 28 Apr 2018 11:51:35 +0200

Hi Jim,

thanks for the encouragement.

> * In section 1 para #4 you appear to have a formatting error where a 
You mean that a list of omitted sections should be added?
> 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
> application/cose type can use 16

Thanks, Will improve the description.
> * Suggest a strong recommendation on not use cmsVersion=1 to make your 

Thanks for the suggestion.
> 
> Jim
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Apr 2018 15:18:16 -0400

> * In section 1 para #4 you appear to have a formatting error where a list

Thanks, I fixed that in the markdown.

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

    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.

-- 
]               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: Jim Schaad <[email-masked]>
Date: Mon, 30 Apr 2018 12:52:24 -0700

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: Monday, April 30, 2018 12:18 PM
> To: [email-masked]; Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: draft-richardson-anima-ace-constrained-voucher
> 
> 
>     >> However I would not want to have to filter through the list of
return
>     >> values
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.

> 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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 30 Apr 2018 13:33:46 -0700

I had to go back and double check that I had things right but there is a
trick that can be played for the PKCS#7 people.

A new content type id-ct-cborVoucher can be defined with the content of
"these are the CBOR encoded bytes".  That is NO ASN.1 wrapper is included.
This works well for CMS 

The people who are stuck in the old world of PKCS #7 can encode this by
using the ASN.1 type of OCTET STRING for this OID.  The
signature/verification process for them will strip the OCTET STRING type and
lengths and just sign/verify the content of the OCTET STRING.  This is the
same as would be done for CMS.

This trick works only if the new content type is OCTET STRING and would fail
for any other ASN.1 type

Jim

return
this