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""".
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""".