Re: [Anima] [Anima-bootstrap] Voucher signing method

[Michael Richardson]

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 what i mean.

Max, can you indicate what your current thinking is in the movement
From PKIX signed custom JSON to ...

  a) JWS signed custom JSON?
  b) JWT, with standard claims?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Kent Watsen]

> 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   
> :1EF9060ADA81C288C4FE2E3585BFF6379FF03467EB0D7D848D568604A1C53864
>36:d=1  hl=2 l=  33 prim: INTEGER   
> :EAD5AD3F8FB7092D14903C8B08D0D83EE91E898EA8D3A5944F13F8B6652372D1
>
> So to do everything in script-land with openssl tools you need to extract
> the r and s values and format them correctly as specified in JWA [RFC7518,
> section 3.4 step 2 and 3). I’ll have to think about how you could do this
> from a shell script. 


Your signature.sign file is probably 66 bytes, right?   Assuming 'R' and 'S' 
are in order, I think you can snip 2-bytes off the front of the file and have 
the signature.


> Its interesting to note here that we have almost the simplest example of
> ASN1 possible and it still sounds hard to work with. :) Shrug, it isn’t
> like the JWA 64-octet sequence is actually that much easier from shell
> commands. 

But all we need to do is compute the encoded signature value BASE64URL(JWS 
Signature), we can use the script I found before for this part...


Kent



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Max Pritikin (pritikin)]

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 (the x5c header) to the JWS?
> 
> 
> The x5c header is defined in JWT but the library I used off github (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 what i mean.

Here is a diff that shows what I mean:

https://github.com/pritikin/libjwt/commit/da7b8b9b59c26f4af6edefaeafb34ffc1f207cca

In summary: JWS defines a {header}.{payload}.signature method. You don’t really 
need a JWT library to do that. I was new to the space and wanted a quick ramp 
up so I used the libjwt library to experiment and found that it hardcoded the 
{header} information and thus couldn’t support the x5c header we were 
discussing. With normal, simple, JWS via a JSON library, you’d just add this 
element like any other normal JSON but because I was using a jwt abstraction I 
had to update the library’s abstraction layer to support arbitrary JSON 
additions to the header. 

- max

> 
>> 
>> Separately, I don't think "-BEGIN CERTIFICATE-" is valid
>> for the 'domain-cert-trusted-ca' field, for which the YANG in 
>> the voucher-02 draft says is a "binary" type field called 
>> 'trusted-ca-certificate'.  If it's type binary, then it's 
>> encoded as just the base64 of the DER, with no PEM header/footer
>> ceremony. See here:
>> 
>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-6.6.
> 
> Totally true. This was discovered at the hackathon too … I just didn’t fix it 
> before looking at the JWT stuff.
> 
> - max
> 
> 
>> 
>> Kent
>> 
>> 
>> -ORIGINAL MESSAGE-
>> 
>> Folks, in Chicago we discussed the signing method for vouchers. 
>> 
>> Because the voucher is JSON, and there is expectation of a CBOR encoding for 
>> future work, there is an open discussion point about using the JWS/COSE 
>> signing methods; if not JWT/CWT. There was brief discussion of this at 
>> IETF98 and one person indicated they liked PKCS7, others indicates JWT and 
>> others did not speak up. Fully meeting minutes might provide more 
>> information but my recollection was that we’d move the discussion to the 
>> list. This thread is for that discussion. 
>> 
>> The current text of draft-ietf-anima-voucher-02 is:
>> 
>>> The voucher is signed a PKCS#7 SignedData structure, as specified by 
>>> Section 9.1
>>> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as 
>>> specified in ITU-T X.690.
>> 
>> 
>> For concrete discussion, the proposed change is:
>> 
>>> The voucher is a JWT [RFC7519] signed token.
>> 
>> 
>> I’ve updated my tooling that was used during the IETF98 hackathon to support 
>> a JWT token format; I did this as homework to be informed for the 
>> discussion. 
>> 
>> MY POSITION: is that I appreciate the simplicity of the JWS signing and feel 
>> it is a good match for us. It was easy enough to implement, was a refreshing 
>> change from the ASN1 complexity of PKCS7, and seems to provide a good path 
>> toward CBOR/COSE in a future document without maintaining PKCS7/CMS 
>> technical debt or revisiting/rewriting too much. 
>> 
>> QUESTION FOR THE WORKING GROUP: What is your position? Why? 
>> 
>> What follows is a dump of the raw JWS before signing (the equivalent 
>> PKCS7/CMS structure would be the SignedData asn1 structures which is hard to 
>> capture). After that is an encoded and signed voucher. Further below is an 
>> example of a PKCS7 signed voucher. 
>> 
>> Please note these characteristics:
>> 
>> a) From JWT RFC7519 "JWTs are always represented using the JWS Compact 
>> Serialization”. There are some JWT headers that overlap with voucher fields. 
>> I’m using JWT here; but the distinction between JWS/JWT is not fundamental 
>> to our discussion. The important point is JWS vs PKCS7. 
>> 
>> b) I’ve added the x5c header to the JWS. This is used to carry the 
>> certificate chain of the signer. Our current voucher format indicates PKCS7 
>> which supports an equivalent field called “CertificateSet structure”. Its in 
>> the BRSKI document that we specify "The entire certificate chain, up to and 
>> including the Domain CA, MUST be included in the CertificateSet structure”. 
>> With the transition to JWT we’d be specifying that the x5c header be fully 
>> populated up to an including the Domain CA etc. 
>> 
>> c) From these examples we can’t directly compare size encodings. I don’t 
>> think this is a significant aspect of the conversation but can create 
>> comparable examples if folks feel that is necessary. 
>> 
>> The dumps:
>> 
>> A debug 

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Kent Watsen]

> 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 structures in the are ASN.1,
and no one has expressed interest in tiny encodings yet.  I'd prefer
it if the voucher draft supported both encodings, and then BRSKI and NETCONF 
zerotouch can cherry-pick their preferred encoding.

Kent


-ORIGINAL MESSAGE-

> 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 cert gets 
> revoked of expires? EST has the transitional certs that allow for root CA 
> cert update, but I don't think we can expect someone to rerun BRSKI in order 
> to get its new root of trust. 
> 
> The cert chain in the voucher should only enable the client to establish a 
> trust relationship with the server. So, I think only one root cert for the 
> domain should be carried in the voucher. The rest of the certs in the chain 
> of the server cert should be sent by the server in the TLS negotiation. 

Yes, this captures the current draft’s position: The voucher provides 
sufficient information to trust the registrar, the pledge communicates with the 
registrar to obtain the rest of the PKI information. 

> About b), optimizing the cacerts response. The truth is that cacerts can grow 
> a lot in size. The enroll response could also be big for constrained 
> environments depending on algorithms used. Some thoughts have been proposed 
> in pkix/tls in the past to shrink certs like caching and compression, but 
> they have some disadvantages. DTLS also provides a fragmentation mechanism in 
> the handshake to accommodate for large records (ca certs in this case). Thus 
> optimizing the responses might not be necessary, or even easy for that 
> matter. 
> 
> Let's say you still wanted to think about it. I don't think JWT or CBOR would 
> add any shrinkage to an ASN.1 cert chain. Now if you are contemplating using 
> a new free-form JSON certificate format (instead of CMS) and then using JWT 
> or CBOR to secure and shrink it, I am not sure about size improvements. CMS' 
> ASN.1 is not human friendly, but I would be interested if writing the cert 
> fields in free-form JSON and encoding with CBOR/JWT would really lead to a 
> shorter total size. In other words, I am not sure going beyond JSON 
> vouchers/tokens when talking about new encodings (JWT, CBOR) is something we 
> should tackle.

I think you’re touching on three issues we should keep them distinct:
1) How a bundle of PKIX certificate is distributed as in the EST /cacerts 
message. This is what is being discussed.
2) out-of-scope: PKIX certificate format.
3) out-of-scope: Size of certificate chains and complexity of the PKI hierarchy.

Lets focus on (1) for now.

Given that the payloads are full certificates (2 and 3) I don’t think its going 
to benefit us to try and chose based on the pure size of the structure. I 
didn’t even bother to ensure comparable structures when I started this thread.

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 defensible based on the (lack of) complexity in 
JWT and the relatively clean way BRSKI *only extends* EST but isn’t optimal for 
clients. Ensuring that the client can use JWT all the way through requires 
overloading that one EST call. That’s a more substantial impact on EST but is 
implied by a transition to JWT. Its a really good point. 

Cheers, 

- max

> 
> Rgs,
> Panos
> 
> 
> 
> -Original Message-
> From: Anima-bootstrap [mailto:anima-bootstrap-boun...@ietf.org] On Behalf Of 
> Max Pritikin (pritikin)
> Sent: Wednesday, April 19, 2017 2:45 PM
> To: consulta...@vanderstok.org
> Cc: anima-bootst...@ietf.org; anima@ietf.org
> Subject: Re: [Anima-bootstrap] Voucher signing method
> 
> 
>> 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 used by BRSKI.
>> All the code is already present.
> 
> Yes: Enrollment over Secure Transport (EST) is *not* intended to be a new 
> enrollment protocol (instead it focused on clarifying how simple CMC messages 
> could be used when a secure transport is available). As such the /cacerts 
> response is a CMC subset "PKCS#7 "certs-only” response”. 
> 
> That is a really heavy structure to deliver what 

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Panos Kampanakis (pkampana)]

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 CA cert update, but 
I don't think we can expect someone to rerun BRSKI in order to get its new root 
of trust. 

The cert chain in the voucher should only enable the client to establish a 
trust relationship with the server. So, I think only one root cert for the 
domain should be carried in the voucher. The rest of the certs in the chain of 
the server cert should be sent by the server in the TLS negotiation. 

About b), optimizing the cacerts response. The truth is that cacerts can grow a 
lot in size. The enroll response could also be big for constrained environments 
depending on algorithms used. Some thoughts have been proposed in pkix/tls in 
the past to shrink certs like caching and compression, but they have some 
disadvantages. DTLS also provides a fragmentation mechanism in the handshake to 
accommodate for large records (ca certs in this case). Thus optimizing the 
responses might not be necessary, or even easy for that matter. 

Let's say you still wanted to think about it. I don't think JWT or CBOR would 
add any shrinkage to an ASN.1 cert chain. Now if you are contemplating using a 
new free-form JSON certificate format (instead of CMS) and then using JWT or 
CBOR to secure and shrink it, I am not sure about size improvements. CMS' ASN.1 
is not human friendly, but I would be interested if writing the cert fields in 
free-form JSON and encoding with CBOR/JWT would really lead to a shorter total 
size. In other words, I am not sure going beyond JSON vouchers/tokens when 
talking about new encodings (JWT, CBOR) is something we should tackle.

Rgs,
Panos

 

-Original Message-
From: Anima-bootstrap [mailto:anima-bootstrap-boun...@ietf.org] On Behalf Of 
Max Pritikin (pritikin)
Sent: Wednesday, April 19, 2017 2:45 PM
To: consulta...@vanderstok.org
Cc: anima-bootst...@ietf.org; anima@ietf.org
Subject: Re: [Anima-bootstrap] Voucher signing method


> 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 used by BRSKI.
> All the code is already present.

Yes: Enrollment over Secure Transport (EST) is *not* intended to be a new 
enrollment protocol (instead it focused on clarifying how simple CMC messages 
could be used when a secure transport is available). As such the /cacerts 
response is a CMC subset "PKCS#7 "certs-only” response”. 

That is a really heavy structure to deliver what is essentially, but not 
exactly, the JWT x5c certificate chain. :(

> Doing JWS/COSE or JWT/CWT needs additional code.
> I am sensitive to the payload size argument though.
> 
> But, suppose the JWS or JWT is adopted to reduce the payload, where 
> will the optimizations stop?
> Will you envisage to optimize the EST payloads as well?

The EST discussion in the -06 concise draft is introduced as: "describes EST 
extensions necessary to enable fully automated bootstrapping”. It adds a couple 
of telemetry (success/fail messages) and mandates a few options that were 
defined in EST but has so far avoided redefining any EST messages. 

Thoughts: 

a) The voucher currently contains the x5c header necessary to deliver the CA 
certificate to move the existing TLS connection out of the provisional state — 
but this is not mandated to be the entire /cacerts chain. The client is 
instructed that:
the domainCAcert is not a complete distribution of the EST 
section 4.1.3 CA Certificate Response.
and
The Pledge MUST request the full EST Distribution of CA Certificates
message.  See RFC7030, section 4.1.
One approach is to ensure the voucher x5c header does contain everything 
necessary. This would allow a client that does not continue to use EST to have 
a full /cacerts equivalent response. Within BRSKI itself this would solve the 
discussion. 

We’re encroaching on redefining that header though (see RFC7515#section-4.1.6 
where it x5c is defined — its a chain directly to the root without any cross 
certifications). If we include PKI /cacerts into there we need to change that 
definition via a new header type so that we can cover the oldwithnew, 
newwithold etc stuff from PKI land.

b) Realistically any PKI client really “MUST” keep their ca certificates up to 
date. (BRSKI tries to frame this as optional to ensure a clean integration 
point for non-PKI type deployments). Therefore we could assume that /cacerts 
will be called and therefore embark on your point: an optimization of at least 
this EST payload. If we do take that path I’d lean