OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: FW: New Version Notification - draft-hammer-hostmeta-09.txt


You can also provide the signed envelope in a 'provenance' element
alongside the unsigned json nv pairs, per the spec. So it can be
ignored easily.  Cost is a 2x blowup in file size.  If defining a new
format, I think its best to just allow envelopes from the start -
bae64urldecode(response.data) is pretty trivial to do.  But either way
could work.

But I think that's minor compared to the trust model.  I assume the
idea with the XML dsig proposal is to use the same ca mechanism used
for tls host verification.  Define it, then define a way to do the
same for magic signatures, and see if the complexity is bearable.

On Monday, May 24, 2010, John Bradley <jbradley@mac.com> wrote:
> No criticism of Magic signatures.
> If all JRD were required to be signed it would be perfect.
> The problem will be that resolving applications will ask for a JRD and potentially get it back in two forms, one with an enveloping signature.It complicates the processing for applications not caring about the signature.
> That is the nice thing about the enveloped signature in XML.
> It is a trade off,  for most things using magic signature it is not a issue.   For the JRD use case I think it adds complexity.
> It is something Nat and I have been looking at when considering Magic signature for use in openID artifact binding.
> Full XML canonicalization is too complex.  We did constrain that in XRD signatures.
> Base64 encoding is not bad but is not perfect for all situations.   I think a simple form of enveloped signature should be possible for JSON though I am not volunteering to develop it.
> Where I think that you don't get value by using Magic Signature to sign a host-meta file is that it simply supports direct key comparison from a XRD.In most cases that would be a bit circular as the XRD is resolved via host-meta.
> We need to clearly understand what is attempting to be achieved by signing a host-meta file and how that fits into a desirable trust model.
> It may be that it doesn't achieve anything more than retrieving the host-meta over https:.   If you want to verify that you have the correct file you can still use Subject and put in an acct: URI like acct:@example.com <acct%3A@example.com>.
> I think it was Google that had some use cases for third party signing of host-meta.
> Unless we really understand what we want, it is simpler to have one format JRD.
> John B.
> On 2010-05-24, at 3:18 PM, Bob Wyman wrote:
> John Bradley <ve7jtb@ve7jtb.com> wrote:
>> [Magic Signatures] adds complexity [by] requiring
>> the unpacking of a base64 encoded file....
> Actually, I think that Magic Signatures *reduces* complexity to the point where it really can't get much simpler. The base64 encoding removes the need for the kind of bizarrely complex canonicalization code that is normally required by signature schemes.
> When trying to figure out why it is that people typically consider signing to be a "complex" problem, it became apparent that for many, many developers, the problem of canonicalization was significant. Thus, the trivially simple base64 approach (proposed by Ben Laurie) was adopted to make canonicalization as easy as possible. The base64 approach also has the nice attribute that the base64 blobs will typically pass through any of the many XML parsing systems without being modified in such a way that data is lost.
>
> John, can you propose a more simple means of doing canonicalization than the one defined by Magic Signatures? If you've got something simpler which is also robust to XML parsers, then I'm sure that there would be significant interest in considering it.
>
> bob wyman
>
> On Mon, May 24, 2010 at 2:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> +1 to the change.
>
> I think especially with JRD it is unclear how a signature relates to <Host> especially given that Magic signatures use raw keys as opposed to X509 certificates.
>
> In many ways magic signature a good thing however it doesn't solve the trust bootstrap problem,  and adds complexity requiring the unpacking of a base64 encoded file.
>
> I think the trust model for host-meta needs more thought.
>
> John B.
>
> On 2010-05-24, at 2:11 PM, Eran Hammer-Lahav wrote:
>
>> The <Host> element as currently specified adds no value to any of the use cases host-meta is intended for. The only reason why it was originally added was to support signatures. At this point it is far from clear how it will actually be used, how to address multiple hosts, and what impact will a JSON serialization will have on signatures (especially when considering "magic signatures").
>>
>> It is a part of the spec no one really cares much about, and removing it doesn't prevent anyone from specifying it elsewhere, where it is actually used.
>>
>> As for last stage, I'm not done with the document and planning on making significant changes to LRDD and integrating them into the same spec. This is based on feedback received over the last couple of weeks.
>>
>> Host-meta didn't even reach IETF last call yet.
>>
>> EHL
>>
>>> -----Original Message-----
>>> From: Breno de Medeiros [mailto:breno@google.com]
>>> Sent: Monday, May 24, 2010 10:56 AM
>>> To: Eran Hammer-Lahav
>>> Cc: xri@lists.oasis-open.org; webfinger@googlegroups.com
>>> Subject: Re: [xri] FW: New Version Notification - draft-hammer-hostmeta-
>>> 09.txt
>>>
>>> -1 to this change.
>>>
>>> Can you explain why the simplification is worth the cost of making a last-
>>> minute change and sowing uncertainty at this last stage?
>>>
>>> On Mon, May 24, 2010 at 10:49, Eran Hammer-Lahav
>>> <eran@hueniverse.com> wrote:
>>>> They can do whatever they want, as long as it is valid according to the XRD
>>> schema. Host-meta leaves <Subject> and <Alias> undefined and not
>>> recommended.
>>>>
>>>> EHL
>>>>
>>>>> -----Original Message-----
>>>>> From: Breno de Medeiros [mailto:breno@google.com]
>>>>> Sent: Monday, May 24, 2010 10:21 AM
>>>>> To: Eran Hammer-Lahav
>>>>> Cc: xri@lists.oasis-open.org;
>

-- 
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]