Skip to content
This repository was archived by the owner on May 7, 2018. It is now read-only.
This repository was archived by the owner on May 7, 2018. It is now read-only.

Elliptic Curve signed assertions are not following the JWS draft standard #30

@jcea

Description

@jcea

Sent to "openbadges@googlegroups.com" 27th november:

"""
I have spend three days debugging this.

I am generating signed openbadges according to
https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#signed-badges.
I am using Elliptic Curves (standard p256) and creating JWS along the
description in
http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html#ES256Example.

In that documentation the signature serialization is described as:

"""
The ECDSA private part d is then passed to an ECDSA signing function,
which also takes the curve type, P-256, the hash type, SHA-256, and the
JWS Signing Input as inputs. The result of the digital signature is the
EC point (R, S), where R and S are unsigned integers.
[...]
The JWS Signature is the value R || S.
"""

Note the last line: the signature is the concatenation of the RAW "R||S".

Checking my signatures with http://validator.openbadges.org/ failed.

After hours/days of checking my code and doing EC signing by hand :-( I
realized that the validator REQUIRES the JWS signature to use DER
encoding. That makes sense, actually, but it is NOT what the JWS draft
mandates.

I would like to know which one is correct: the JWS draft or the
Openbadges Validator.

Please, reply.

Thanks!.
"""

I reproduce this trivially using Elliptic Curves crypto (P256).

Example of an signed assertion passing the test at http://validator.openbadges.org/ , using DER encoding for the signature, intead of the "standard required" raw R+S values:

"""eyJhbGciOiAiRVMyNTYifQ.eyJiYWRnZSI6ICJodHRwczovL29wZW5iYWRnZXMubHVpc2dmLmVzL2lzc3Vlci9iYWRnZS1sdWlzZ2YuanNvbiIsICJyZWNpcGllbnQiOiB7Imhhc2hlZCI6ICJ0cnVlIiwgImlkZW50aXR5IjogInNoYTI1NiRlMWNlNDc4NDUyOGM3ZGY5YmI2YTA0ZmRmZjRjZjU1OTZiOWM1MjNhN2U0MGE2MzVmYjZkYWJhYjhjZDIzYjEwIiwgInR5cGUiOiAiZW1haWwifSwgImltYWdlIjogImh0dHBzOi8vb3BlbmJhZGdlcy5sdWlzZ2YuZXMvaXNzdWVyL2JhZGdlcy9pbWFnZS5wbmciLCAidWlkIjogIjQ3M2NmNmRiYTJlOGYzNjRkM2UxNjc1YmRiMGY0NDg5MGM4ZjJjMzYiLCAiaXNzdWVkT24iOiAxNDE2OTEyNjQ1LCAidmVyaWZ5IjogeyJ1cmwiOiAiaHR0cHM6Ly9vcGVuYmFkZ2VzLmx1aXNnZi5lcy9pc3N1ZXIvcHVia2V5cy92ZXJpZnkucGVtIiwgInR5cGUiOiAic2lnbmVkIn19.MEQCIC69pvqBaN_2W03DXalJ0XFhb8zm-j9sfjmjy-ZbuaKQAiAz43dgcwmvYBek00_ShOFs4qSRAX-MRFmMDrFqNE3nLQ""".

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions