[Cryptography Team] ASN1WrapperConstructedType and ASN1ExplicitContextValue use

Sat Sep 10 02:43:19 UTC 2022

Hi Rob,

Excellent.  Glad to hear it.

Ron

On Fri, Sep 9, 2022 at 10:41 PM rabbit <rabbit at callistohouse.org> wrote:

> I cannot figure out how to respond to a previous email in Apple’s Mail
> client.
>
> I am thinking now I do not need to figure out ASN1WrapperConstructedValue
> or the ExplicitContextType. I am not going to be passing objects that do
> not have an ASN1 map defined. The objects I am passing are well known, many
> passByCopy and all others passed as FarObjects, with ASN1 defined message
> passing. I’m switching RemotePromises from encoding with STON to encoding
> with ASN1. My STON tests was testing anonymous Object instances, without
> using maps. I need to change the tests to test all the ASN1 maps. Awesome!
>
>
> Have a good one; keep it, light.
> Kindly,
> rabbit
> . .. … ‘…^,^
>
>
> Sent from Callisto House :: decentralized mobile homeless solutions
>
> On Sep 9, 2022, at 20:39, rabbit <rabbit at callistohouse.org> wrote:
>
> Oh! I thought you were over UDP with TeaTime, I believe it was called.
> You guys already have an open spec for metaverse traffic! Add ObjCaps and
> the sky is the limit with secure transactions. It is everything Meta is
> trying to define and promote. You already have the solution!
>
> Have a good one; keep it, light.
> Kindly,
> rabbit
> . .. … ‘…^,^
>
>
> Sent from Callisto House :: decentralized mobile homeless solutions
>
> On Sep 9, 2022, at 20:28, Ron Teitelbaum <ron at usmedrec.com> wrote:
>
> 
> HI Rob,
>
> I see.  We are using TCP secure sockets now with our own protocol to do an
> overlay network to allow for network prioritization.  It all runs over one
> port which makes proxy support simple. The overlay network allows us to
> limit traffic to what is most important.  Since we are not passing a huge
> amount of data we don't use UDP.  Maybe at some point in the future it
> would be a good idea to look into it.  I don't think it is necessary now.
> It might be interesting to look into UDP for 3D object data sometime in the
> future.  Thanks for the offer.
>
> All the best,
>
> Ron
>
>
>
>
> On Fri, Sep 9, 2022 at 8:19 PM rabbit <rabbit at callistohouse.org> wrote:
>
>> Hey, yes I was think of getting ParrotTalk working over UDP, then
>> RemotePromises on top of that, then place it underneath Croquet to combine
>> a metaverse communications protocol with distributed secure
>> object-capabilities alongside.
>>
>> My latest ParrotTalk iteration is to get my SPADS Server working. The
>> SPADS server will have multiple installed secure protocols (ParrotTalk
>> v3.6, v3.7 & v3.8 as well as SSL 1.0, TLS 1.2, perhaps TLS 1.3 (with
>> elliptical DH) and SSH. There is a probing frame buffer just above the
>> socket thunk with protocol frame probes which
>>
>>
>> Have a good one; keep it, light.
>> Kindly,
>> rabbit
>> . .. … ‘…^,^
>>
>>
>> Sent from Callisto House :: decentralized mobile homeless solutions
>>
>> On Sep 9, 2022, at 20:10, Ron Teitelbaum <ron at usmedrec.com> wrote:
>>
>> 
>> Hi Rob,
>>
>> Yeah I'm still working on Croquet at 3D Immersive Collaboration Corp
>> www.3dicc.com.  We renamed our product from Immersive Terf, before that
>> Teleplace, and  before that Qwaq, to Virtend.  As in you can virtually
>> attend a meeting.
>>
>> UDP can be encrypted but since the stream itself is not guaranteed you
>> would need to encrypt each datagram.  I believe there is a good method for
>> this using DTLS.  https://www.rfc-editor.org/rfc/rfc4347.txt.
>>
>> All the best,
>>
>> Ron Tetielbaum
>>
>> On Fri, Sep 9, 2022 at 5:03 PM rabbit <rabbit at callistohouse.org> wrote:
>>
>>> HAH HAH HAH HAH!!!
>>>
>>> Yessir, it was a long time ago. According to your methods
>>> in ASN1ExplicitContextValue, it was 16 years ago, yesterday! .  ..   ….
>>> ‘…^,^
>>>
>>> I am still undecided. Should Crypto ASN1 type structures (DSAPublicKey,
>>> and such) be of an application variety? But WrapperPrimitive perhaps, not
>>> constructed.
>>>
>>> You said: [  I believe that for Objects this makes sense if we are
>>> encoding them but you could easily encode them as class name with a bucket
>>> of values with default encoding. ]
>>>
>>> Yes, I’ll need to see about this. Some sort of
>>>
>>>     ASN1 tagValues:= object class instVarNames
>>>         collect: [ :ivarName | object instVarAt: ivarName ].
>>>     ^ Array with: object className with: tagValues.
>>>
>>> You also wrote: [Wish I had more time to work on this but I'm sorry I
>>> don't right now.  Good luck with it.  Let me know what you decide to do
>>> with it.  Happy to try and keep up to date on it.]
>>>
>>> What is keeping you busy these days?
>>>
>>> Didn’t you work with Croquet? Do you think ParrotTalk could talk and
>>> encrypt over UDP? I don’t understand how UDP works. :(
>>>
>>> Cheers!
>>>
>>> Have a good one; keep it, light.
>>> Kindly,
>>> rabbit
>>> . .. … ‘…^,^
>>>
>>>
>>> Sent from Callisto House :: decentralized mobile homeless solutions
>>>
>>> On Sep 9, 2022, at 12:58, Ron Teitelbaum <ron at usmedrec.com> wrote:
>>>
>>> 
>>> Hey Rob,
>>>
>>> I'm not sure it was a long time ago.  My understanding of the
>>> application flag is that it is for encoding tags that are application
>>> specific and not for ASN1 defined values.  So the Context is an Application
>>> context not a default value.  If we have a specific context and special
>>> rules for encoding or decoding a value it would be marked as application
>>> otherwise it should be marked as non-application specific to handle it
>>> using default rules.  I believe that for Objects this makes sense if we are
>>> encoding them but you could easily encode them as class name with a bucket
>>> of values with default encoding.
>>>
>>> Wish I had more time to work on this but I'm sorry I don't right now.
>>> Good luck with it.  Let me know what you decide to do with it.  Happy to
>>> try and keep up to date on it.
>>>
>>> All the best,
>>>
>>> Ron Teitelbaum
>>>
>>> On Fri, Sep 9, 2022 at 11:11 AM rabbit <rabbit at callistohouse.org> wrote:
>>>
>>>> Hi Ron,
>>>>
>>>> I see that originally when you had introduce ASN1 to our library, you
>>>> defined the classes ASN1WrapperConstructedType and
>>>> ASN1ExplicitContextValue. I tried to implement decode and encode to
>>>> ASN1WrapperConstructedType, but only partially. I used your
>>>> ASN1ExplicitContextValue but have not completed it. Now I have the need to
>>>> implement, as I attempt to switch the PromisesRemote to using ASN1
>>>> encoding, rather than STON.
>>>>
>>>> In looking at Object>>#asn1Tag we construct a tag with
>>>>
>>>> Object>>#asn1Tag
>>>>
>>>>     ^ (ASN1MappedSequenceType new asn1Tag "48"
>>>>             bitOr: 2r11000000) "Application"
>>>>             bitOr: 2r00100000 "Constructed"
>>>>
>>>> So we are an application class and constructed. In
>>>> ASN1OutputStream>>#typeForTag: tag, the tag is broken down into the
>>>> numericTag, the tagClass (application) and whether it is constructed. This
>>>> is called from decode: anObject with the call:
>>>>
>>>> ^ self encode: anObject with Type: (self typeForTag: anObject asn1Tag)
>>>>
>>>> So Object>>#asn1Tag is called. So with a ASN1 non-registered object, we
>>>> end up with a ASN1WrapperConstructedType.
>>>>
>>>> I am totally unsure about how the ASN1ExplicitContextValue should be
>>>> used with the ASN1WrapperConstructedType, nor how it builds the context
>>>> from the ivars of the provided anonymous object.
>>>>
>>>> My related concern is whether all of the crypto objects with ASN1
>>>> definitions ought to be of the application tagClass.
>>>>
>>>> Any guidance you could provide me for this would be very welcome! If it
>>>> is not too far back in history! Heh!
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Have a good one; keep it, light.
>>>> Kindly,
>>>> rabbit
>>>> . .. … ‘…^,^
>>>>
>>>> Sent from Callisto House :: decentralized mobile homeless solutions
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20220909/ba21090f/attachment.html>