Max Pritikin (pritikin) wrote:
> (libjwt) didn’t support it. After looking at the code more closely I’m
> not sure a jwt abstraction layer is really even needed; JWS is pretty
> simple to use directly. I’ve forked libjwt and will upload my diff to
> github tomorrow so you can see
Kent Watsen wrote:
> BTW, ES256 uses the P-256 curve (aka secp256r1) which has since been
> deprecated. I got a kick out of RFC 7518 giving it a "recommended+"
> rating ;)
Yeah, in my work, I've had to sue secp256r1 because the examples are in that,
and the libraries are up-to-date
> On May 2, 2017, at 7:22 PM, Kent Watsen wrote:
>
>
> I've had some time now to investigate JWS, in particular, reproducing some
> examples in RFCs 7515 and 7520 using nothing but shell scripts and the
> `openssl` command line utility.
Excellent. I look forward to hearing what tool you used
BTW, ES256 uses the P-256 curve (aka secp256r1) which has since been
deprecated. I got a kick out of RFC 7518 giving it a "recommended+" rating ;)
K.
-ORIGINAL MESSAGE-
I've had some time now to investigate JWS, in particular, reproducing some
examples in RFCs 7515 and 7520 using n
I've had some time now to investigate JWS, in particular, reproducing some
examples in RFCs 7515 and 7520 using nothing but shell scripts and the
`openssl` command line utility.
I want to like JWS, but I wish the header was in a more technology-neutral
format, it being JSON seems weird to me.
Panos Kampanakis (pkampana) wrote:
> About a), I don't think putting all the CA certs in the voucher is a
> good idea. EST should be used instead. I don’t think it is right for
> someone to expect the voucher to distribute its roots of trust. What if
> a CA cert gets revoked of ex
peter van der Stok wrote:
> thanks for the examples. During IETF98, I was the one to speak up in
> favour of #pkcs7; One reason only: It is transported by EST that is
> used by BRSKI. All the code is already present. Doing JWS/COSE or
> JWT/CWT needs additional code. I am sens
> You can see this by exploding the output from openssl dgst via asn1parse:
> pritikin@ubuntu:~/tmp/jwt$ openssl asn1parse -in signature.sign -inform DER
> 0:d=0 hl=2 l= 69 cons: SEQUENCE
> 2:d=1 hl=2 l= 32 prim: INTEGER
> :1EF9060ADA81C288C4FE2E3585BFF6379FF0346
Kent,
> On Apr 21, 2017, at 4:51 PM, Max Pritikin (pritikin)
> wrote:
>
>>
>> On Apr 21, 2017, at 1:50 PM, Kent Watsen wrote:
>>
>> Hi Max,
>>
>> I think what you're trying to say is that the x5c header is not under
>> the signature and therefore can be added after the fact using any text-
> On Apr 21, 2017, at 1:50 PM, Kent Watsen wrote:
>
> Hi Max,
>
> I think what you're trying to say is that the x5c header is not under
> the signature and therefore can be added after the fact using any text-
> editing tool. Is that right?
No, "In the JWS Compact Serialization, no JWS Unprote
Hi Max,
I think what you're trying to say is that the x5c header is not under
the signature and therefore can be added after the fact using any text-
editing tool. Is that right?
Actually, for that matter, I imagine that the entire thing could be
constructed without the use of a JWT library - si
Kent,
> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin)
> wrote:
>
>>
>> On Apr 20, 2017, at 6:51 PM, Kent Watsen wrote:
>>
>>
>> Hi Max,
>>
>> I'd like to reproduce your experiment, but I can't find a library
>> that supports the 'x5c' header. What do you mean that you added
>> it
> On Apr 20, 2017, at 6:51 PM, Kent Watsen wrote:
>
>
> Hi Max,
>
> I'd like to reproduce your experiment, but I can't find a library
> that supports the 'x5c' header. What do you mean that you added
> it (the x5c header) to the JWS?
The x5c header is defined in JWT but the library I used o
Hi Max,
I'd like to reproduce your experiment, but I can't find a library
that supports the 'x5c' header. What do you mean that you added
it (the x5c header) to the JWS?
Separately, I don't think "-BEGIN CERTIFICATE-" is valid
for the 'domain-cert-trusted-ca' field, for which the YANG i
> On Apr 19, 2017, at 3:59 PM, Kent Watsen wrote:
>
>
>> I think Peter’s point is that moving to JWT for the voucher signature
>> but depending on PKCS#7 in the /cacerts exchange results in client’s
>> being required to handle both formats.
>
> This is one of my issues, when thinking about the
> I think Peter’s point is that moving to JWT for the voucher signature
> but depending on PKCS#7 in the /cacerts exchange results in client’s
> being required to handle both formats.
This is one of my issues, when thinking about the NETCONF zerotouch
bootstrapping draft, as all the other structu
> On Apr 19, 2017, at 2:24 PM, Panos Kampanakis (pkampana)
> wrote:
>
> About a), I don't think putting all the CA certs in the voucher is a good
> idea. EST should be used instead. I don’t think it is right for someone to
> expect the voucher to distribute its roots of trust. What if a CA ce
About a), I don't think putting all the CA certs in the voucher is a good idea.
EST should be used instead. I don’t think it is right for someone to expect the
voucher to distribute its roots of trust. What if a CA cert gets revoked of
expires? EST has the transitional certs that allow for root
> On Apr 19, 2017, at 1:01 AM, peter van der Stok wrote:
>
> Hi Max,
>
> thanks for the examples.
> During IETF98, I was the one to speak up in favour of #pkcs7;
I thought so but wasn’t sure and the minutes didn’t appear to be available.
> One reason only: It is transported by EST that is us
Hi Max,
thanks for the examples.
During IETF98, I was the one to speak up in favour of #pkcs7;
One reason only: It is transported by EST that is used by BRSKI.
All the code is already present.
Doing JWS/COSE or JWT/CWT needs additional code.
I am sensitive to the payload size argument though.
Bu
20 matches
Mail list logo
