Re: Last Call for Comments on Crypto-Conditions

So, I finished the updates and have dropped that old PR in favour of a
clean one that will make it easier to track comments.

https://github.com/interledger/rfcs/pull/131

I realize there is some big changes there but this is all based on valuable
feedback from both the community and experts at IETF.

The most significant change is to use DER encoding. This is the de-facto
standard among the crypto-community. This (and re-using existing key
definitions) means existing DER encoded data such as RSA keys can simply be
dropped into a condition/fulfillment without needing to be decoded and
re-encoded

I'm going to put this on the agenda for Wednesday's call to discuss further

On 12 December 2016 at 17:13, Steven Roose <stevenroose@gmail.com> wrote:

> Hi again
>
>
> It seems that the five-bells (I see it as the reference implementation)
> has unit tests that test for stronger requirements than the spec. It
> requires the implementation to use Canonical OER, while the spec does not
> mention whether Basic OER or Canonical OER is to be used.
>
> It might be a good idea to state that explicitly.
> I create a GitHub issue regarding this here:
> https://github.com/interledgerjs/five-bells-condition/issues/60
>
>
> Best
>
> Steven
>
>
> On 08-12-16 22:11, Adrian Hope-Bailie wrote:
>
>> Hi all,
>>
>> For almost a year we've been working to refine the crypto-conditions
>> specification [1]. Stefan talked about them in detail as part of the Ledger
>> BOF [2] at IETF 96 in Berlin and recently I was at IETF 97 in Seoul where I
>> presented the latest draft[3] to the SAAG.
>>
>> We've had some great feedback which we have incorporated, but given the
>> nature of the work, it is important that we eventually settle on a stable
>> specification so that implementors can begin to use crypto-conditions
>> confidently, in the knowledge that they will inter-operate with other
>> implementations.
>>
>> At the end of next week (16 December) we will stop taking input on this
>> version of the specification and aim to have a final draft out for comments
>> soon after. Following this we'd like to limit changes to editorial or style
>> changes only and make no further functional changes.
>>
>> If anyone has breaking functional changes they wish to suggest please
>> make these on this list or via the Github issue list before 16 December
>> otherwise they will only be considered for the next major version of the
>> specification.
>>
>> Thanks,
>> Adrian
>>
>> [1] https://github.com/interledger/rfcs/blob/master/0002-crypto-
>> conditions/0002-crypto-conditions.md
>> [2] https://youtu.be/uPXXfClTqSY?t=49m
>> [3] https://tools.ietf.org/html/draft-thomas-crypto-conditions-01
>>
>
>
>