On Jul 23, 2013, at 12:49 AM, Anders Rundgren <[email protected]> wrote:
> On 2013-07-18 17:21, Phillip Hallam-Baker wrote:
>> I agree that enveloped signatures are useful. But trying to do that in XML
>> or JSON is quite painful without resort to Base64 encoding or the like.
>
> I have used enveloped XML signatures in XML for about 10 years and the only
> problem I have experienced is the many options which makes interoperability
> difficult.
Me too, although I’ve experienced a few security and interoperability issues
with a static set of options chosen ;-)
The big issue that I see is that JSON parsers are diverse enough across
implementations that you wont be able to round trip into a canonical form
without defining some additional limitations on supportable parser
functionality. The big examples are numerical representations (not all
languages even support infinite floating point precisions) and the behavior
when multiple identical elements are found.
You also have implementations which represent as object types internally,
meaning that an ISO 8601 date may be a Date object in some implementations and
a non-declared key on an object might be represented internally by a value
‘false’. This brings back some of the DTD and schema-related canonicalization
issues in XML if you don’t specifically disallow it.
You also have two root types in JSON; object and array. An enveloped signature
on an array would not be transparent like your object example below, because
the signature would be a member of the array.
Without the ability to round-trip data, you could choose a preprocessing route,
where signature verification happens before you load into the JSON engine. You
then have a choice between making your wire form look like JSON (and risk
having implementations parse and regenerate causing a non-canonical transform),
or make it look like something else so that you require new tooling to support
it.
And if you decide to make it look like something else, you probably have JWS :-)
-DW
> Although I haven't yet decided on switching to JSON (for market adoption
> reasons only, technically there's no need at all) I have come up with a
> scheme that inherits stuff from JWS that could work:
>
> {
> "ElementToBeIncludedInTheEnvelopedSignature": {
> "arbitrary_but_required_identifier_and_unique_data": "5fr70ydte",
> "PayloadData": "The_meat_of_the_message",
> "envelopedsignature": {
> "arbitrary_but_required_identifier_and_unique_data": "5fr70ydte",
> "protected": "integrity_protected_header_contents",
> "header": "non_integrity_protected_header_contents",
> "signature": "signature_contents"
> }
> }
> }
>
> Naturally you need a canonicalization scheme but I believe it could be quite
> simple and still even support multiple signatures.
>
> Anders
>
>>
>> The problem is where to define the start and end of the signed text. Add
>> some whitespace, do a trivial reformat and the position is lost.
>>
>> This is where ASN.1 has an advantage over JSON. Which would be fine if it
>> didn't also come with so many disadvantages. ASN.1 is the CPL of binary
>> encodings and XML is the CPL of text encodings.
>>
>> Fortunately we now have JSON which is the C of text encodings. It may not be
>> pretty, it may not support every need but it does the job for 95% of all
>> needs. Unfortunately there remains a 5% in which there is no substitute for
>> a binary encoding.
>>
>> Which is the reason Casten and Paul have been looking at CBOR and while I
>> have been working on JSON-B, C and D.
>>
>> http://tools.ietf.org/html/draft-hallambaker-jsonbcd-00
>>
>>
>> What I am trying to do here is not compete with JSON for the purposes that
>> JSON is good at. In fact a compliant JSON-B reader will read JSON without
>> modification, a JSON-B reader will read JSON or JSON-B and a JSON-C reader
>> will read any of them.
>>
>> The idea of JSON-BCD is not to compete with JSON, it is to minimally extend
>> the JSON syntax so as to address the missing 5% in which binary is essential
>> so that we can use JSON to drive a steak through the heart of ASN.1
>> (preferably fillet).
>>
>>
>> I would like to use JSON-B as a wrapper for Jose data.
>>
>>
>>
>> On Thu, Jul 18, 2013 at 4:45 AM, Anders Rundgren <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>> I'm hooked on enveloped signatures i XML. I'm considering dropping XML
>> for JSON.
>> I guess enveloped signatures won't be a part of JWS?
>>
>> Why enveloped signatures you may wonder?
>> Well, in most schemes the root/top element is the message/type indicator
>> and it is of course nice if a signature can cover the entire message.
>>
>> thanx
>> Anders
>>
>> <ProvisioningInitializationResponse
>> Attestation="NxcMqBJGQi...hcKoS2wPQm7rvRc="
>> ClientTime="2013-07-09T18:13:52+02:00"
>> ID="C-13fc435e15fe1f9c7534beb0a08"
>> ServerSessionID="S-13fc435e0099bb7345b0bf57a85"
>> ServerTime="2013-07-09T18:13:52+02:00"
>> xmlns="http://xmlns.webpki.org/keygen2/beta/20121228#";
>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
>> xmlns:ds11="http://www.w3.org/2009/xmldsig11#";>
>> <ClientEphemeralKey>
>> <ds11:ECKeyValue>
>> <ds11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/>
>>
>> <ds11:PublicKey>BEdD3W6GslfY/AVEkRTD8MqT2R24iYnb+qvs2zP8PWXfecMNioEYR5P1VWPnKLPbRm1JMWPNrgBcTrBPebJ0eKc=</ds11:PublicKey>
>> </ds11:ECKeyValue>
>> </ClientEphemeralKey>
>> <DeviceCertificatePath>
>> <ds:X509Data>
>>
>> <ds:X509Certificate>MIIC2DCCAcCgAwIBAg...xtVD5cD1Gcn7KNdcJfLt</ds:X509Certificate>
>> </ds:X509Data>
>> </DeviceCertificatePath>
>> <ds:Signature>
>> <ds:SignedInfo>
>> <ds:CanonicalizationMethod
>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> <ds:SignatureMethod
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
>> <ds:Reference URI="#C-13fc435e15fe1f9c7534beb0a08">
>> <ds:Transforms>
>> <ds:Transform
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>> <ds:Transform
>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </ds:Transforms>
>> <ds:DigestMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
>>
>> <ds:DigestValue>bQymGISGazFazPrSFcl45YrUBYPzF1sZ1O+29zpfx+w=</ds:DigestValue>
>> </ds:Reference>
>> </ds:SignedInfo>
>>
>> <ds:SignatureValue>ZN1QM20uWIfHd4rloiqtQqRRf6jAgifcFlzNxqlnk84=</ds:SignatureValue>
>> <ds:KeyInfo>
>> <ds:KeyName>derived-session-key</ds:KeyName>
>> </ds:KeyInfo>
>> </ds:Signature>
>> </ProvisioningInitializationResponse>
>>
>> _______________________________________________
>> jose mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
