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: [xri] Re: Mime type for XRD/Site-meta signature file


+1 to the simple scheme.

On Wed, Dec 3, 2008 at 3:50 PM, Brian Eaton <beaton@google.com> wrote:
> I love the simple sign approach, in particular that it chooses to sign
> a literal string of bytes that is easily reconstructed.
>
> The OAuth canonicalization is relatively simple if you're dealing with
> name/value pairs, but to be honest the spec has been final for over a
> year and we are still finding occasional compatibility issues due to
> canonicalization.
>
> On Wed, Dec 3, 2008 at 2:29 PM, Peter Davis <peter.davis@neustar.biz> wrote:
>> FWIW, it might be worthwhile looking at the proposed simple-sign binding
>> draft [1] in the SSTC (SAML).  Much thought has gone into this over the past
>> year or so, and might save us sime time, if we really want to consider
>> ditching xml dsig.
>>
>> =peterd
>>
>> [1]
>>  http://www.oasis-open.org/apps/org/workgroup/security/download.php/30234/sstc-saml-binding-simplesign-cd-04.pdf
>>
>> On Dec 3, 2008, at 5:20 PM, Eran Hammer-Lahav wrote:
>>
>>> (moving this thread to XRI TC)
>>>
>>> Some questions:
>>>
>>> Is S/MIME adopted? It seems to work very similarly to what we are looking
>>> for, though using multiparts and not links.
>>> Do we have an idea how the current status of adoption for PKCS #7 in
>>> libraries and platforms?
>>> How much signature metadata do we need to build into XRD?
>>>
>>> EHL
>>>
>>>
>>> On 12/3/08 10:14 AM, "Brian Eaton" <beaton@google.com> wrote:
>>>
>>> OK, here's why you should care:
>>>
>>> If we use PKCS #7, we get a signature scheme that works on arbitrary
>>> documents (xml, binary, json, whatever) that includes all of the kinds
>>> of metadata one looks for in such signatures, such as who signed the
>>> document, when they signed, etc...
>>>
>>> The downside to PKCS #7 is that it is somewhat hard to implement from
>>> scratch due to asn.1, and we all know that developers prefer to
>>> implement something simple themselves than pulling in a complicated
>>> library.
>>>
>>> If we use PKCS #1 we need to build signature metadata into XRD.
>>> That's not particularly hard, we can reference the relevant XML DSIG
>>> formats without pulling in the insanity of xml canonicalization.
>>>
>>> So at this point I'm voting for pkcs #1, but there are valid arguments
>>> for pkcs #7 as well.
>>>
>>> Cheers,
>>> Brian
>>>
>>> On Wed, Dec 3, 2008 at 9:51 AM, Eran Hammer-Lahav <eran@hueniverse.com>
>>> wrote:
>>> > This means nothing to me... :-)
>>> >
>>> > I'm going to leave the crypto stuff to those who truly understand it.
>>> >
>>> > EHL
>>> >
>>> >> -----Original Message-----
>>> >> From: Brian Eaton [mailto:beaton@google.com]
>>> >> Sent: Wednesday, December 03, 2008 9:44 AM
>>> >> To: Eran Hammer-Lahav
>>> >> Cc: Ben Laurie
>>> >> Subject: Re: Mime type for XRD/Site-meta signature file
>>> >>
>>> >> pkcs #7 wraps the raw pkcs #1 signature with some additional asn.1
>>> >> The format is in http://tools.ietf.org/html/rfc2315 if you're
>>> >> interested.
>>> >>
>>> >> On Wed, Dec 3, 2008 at 9:40 AM, Eran Hammer-Lahav <eran@hueniverse.com>
>>> >> wrote:
>>> >> > I have no clue what the difference between 1 and 7 is... I simply
>>> >> looked for an existing signature mime-type and found this...
>>> >> >
>>> >> > Ben and Jonathan Sergent submitted the OAuth proposal for PKCS #1.5
>>> >> and we never discussed it.
>>> >> >
>>> >> > EHL
>>> >> >
>>> >> >> -----Original Message-----
>>> >> >> From: Brian Eaton [mailto:beaton@google.com]
>>> >> >> Sent: Wednesday, December 03, 2008 9:37 AM
>>> >> >> To: Ben Laurie
>>> >> >> Cc: Eran Hammer-Lahav
>>> >> >> Subject: Re: Mime type for XRD/Site-meta signature file
>>> >> >>
>>> >> >> On Wed, Dec 3, 2008 at 2:08 AM, Ben Laurie <ben@links.org> wrote:
>>> >> >> > Eran Hammer-Lahav wrote:
>>> >> >> >> I am not sure which signature method you had in mind, but if it
>>> >> is
>>> >> >> PKCS7,
>>> >> >> >> would application/pkcs7-signature work as a mime-type?
>>> >> >> >
>>> >> >> > I can't see any harm in that.
>>> >> >>
>>> >> >> Why did the OAuth community decide to go with PKCS #1.5 instead of
>>> >> PKCS
>>> >> >> #7?
>>> >> >>
>>> >> >> There seems to be a certain amount of overlap between the XML DSIG
>>> >> >> schema and the PKCS #7 ASN.1 schema.  Both include mechanisms for
>>> >> >> transferring certificates, for example.  My concern about using PKCS
>>> >> >> #7 signatures instead of using PKCS #1 is that some platforms may
>>> >> not
>>> >> >> have standard libraries for parsing PKCS #7 objects.  For example,
>>> >> >> Sun's JCE doesn't seem to expose PKCS #7 signature verification
>>> >> tools.
>>> >> >>  They do expose tools to verify PKCS #1 signatures.
>>> >> >
>>> >
>>>
>>
>> Peter Davis: NeuStar, Inc.
>> Director & Distinguished Member of the Technical Staff
>> 45980 Center Oak Plaza Sterling, VA 20166
>> [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W]
>> http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd
>> The information contained in this e-mail message is intended only for the
>> use of the recipient(s) named above and may contain confidential and/or
>> privileged information. If you are not the intended recipient you have
>> received this e-mail message in error and any review, dissemination,
>> distribution, or copying of this message is strictly prohibited. If you have
>> received this communication in error, please notify us immediately and
>> delete the original message.
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)


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