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