[core] Reply to comments on raza-ace-cbor-certificates

[Joel Höglund <[e-mail]>]

Hi Michael,

Thanks for the comments, sorry for late response. Please find responses
inline below.

“If we transcode ASN.1 to CBOR rather than DER in a way that preserves the
signature, then I think we miss all opportunities to throw away the DER
code.”

This is a valid remark, in the sense that a signature, which is computed
and added as a part of an original -- profiled but uncompressed --
certificate structure, can only be verified after recreating the original
uncompressed structure.

“If we can outsource this to a third party to verify, we can just throw the
DER itself to the third party, and wrap it in a RESTful COAP interface.”

One of our goals is to keep end to end security. Which means we generally
don’t want to outsource anything / to be forced to trust additional
parties. Our discussions have been along the lines that the cbor encoding could
become a native encoding option, in which case the ASN1-DER encoding could
be skipped and the signature computed and added directly on the smaller
cbor encoded data structure. But I don’t see that neither the current
“needs to recreate the initial structure” nor a native implementation would
rule out outsourcing verification to third parties, if one would want that.

“I see two issues with PKIX certificates:

a) DNs never made any sense in 1980 when a company could have three people
named John Smith, and they make even less sense now that we have 10,000
light bulbs whose name is "serialNumber=XXXXX"

b) while subject DNs can be empty, issuer DNs can't be empty if you want to
verify the certificate.Finding the public key of the issuer to verify the
certificate is annoying and often non-trivial. There are PKIX extensions to
deal with this, but they aren't mandatory.

These are essentially issues with how the certificate semantics are encoded
into the ASN.1, not really a problem with the DER itself. The lack of good
DER encoders/decoders (I've never seen a pull parser, I'm sure Heimdal
includes one, but I've never seen it) is the PITA.”

We haven’t addressed how an IoT client should act if it does not already
have a relevant certificate/the relevant public key of the issuer of a
certificate that it needs to verify, or the reverse. I have assumed this to
be separate issues. As long as the subject and issuer can be uniquely
identified within their target scope (which might or might not be the
entire internet), I don’t think our proposal is making the problems he
describes worse. But I’m happy to hear more opinions if you think there are
details regarding this we should expand or try to clarify.

The certificates we have used as basis for the comparisons made in the
draft are taken from IoT security projects we have been working with. We
welcome if other working group members want to contribute additional
examples of relevant certificates to compare with.


"I couldn't figure out what the conclusion of your slides were, btw."

I agree it was not spelled out sufficiently clear. The main conclusions are:

1. We can significantly reduce message overhead of X.509 certificates which
is beneficial when transported over constrained networks.  Indeed,
substantially better than e.g. the TLS compression scheme zlib (see
draft-ietf-tls-certificate-compression) as we show in the next version of
the draft.

2. CAs can maintain their current X.509 based infrastructure and include
this as a compression front end.

3. The certificate format is a candidate native format for IoT device
certificates. This would require changes in the CA, but would reduce
processing and memory use in particular in the IoT device which does not
require ASN.1 or DER. The compression step provides a migration path where
the CAs and device manufacturers can support compressed standard X.509 and
native CBOR certificates in parallel (e.g. different device batches)

Best Regards

Joel Höglund