> On the openssl-user list, the claim was made that concatinating DER
> certs for a cert chain like you do with PEM does not work with
> applications. You have to use PKCS#12, but that includes the private
> key and is passworded. I should be able to get the pointer to Viktor's
> post about this.
Concatenating PEM encodings into a single file is a hack, albeit a super
convenient one. Instead of PKCS#12, have you looked into PKCS#7? - this
is what is used in the netconf-zerotouch draft for binary certificate
chains.
> Here is where you'd find objects in BRSKI:
>
> 1) TLS ClientCertificate.
> This should be just the IDevID blob, and in TLS, it's in DER format,
> if the Registrar needs anything else in the chain, it must chase them down
> itself.
FWIW, the netconf-zerotouch draft specifies that the device possesses the
IDevID cert *and* all the intermediate certs leading to the manufacturer's
well-known trust-anchor, all of which it provides during crypto handshake.
> 2) TLS ServerCertificate.
> https://tools.ietf.org/html/rfc5246#section-7.4.2
> Note: PKCS #7 [PKCS7] is not used as the format for the certificate
> vector because PKCS #6 [PKCS6] extended certificates are not used.
> Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
> of parsing the list more difficult.
I don't understand how this relates to PKCS#6. True about the SET, but this
is minor relative to the tradeoffs. Can you say some more about this?
> 3) The plege's Voucher Request may be signed using JOSE (using the IDevID)
> The IDevID is not sent, it's the one from ClientCertificate.
>
> 4) The registar's Voucher Request may be signed using JOSE, using the
> Domain Owner's key. That might not be the same key the Registrar uses
> to form the EST connection to the MASA (if the Registrar uses client
> authentication at all).
> The Domain Owner is within the pinned-domain-cert field.
> We define it as being DER binary. In JSON format, that turns into base64
> encoded. The reason we go there is that we do not want the
> ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary
> is just fine.
Correct, putting PEM-text into protocols is inappropriate.
> 5) The resulting voucher also uses pinned-domain-cert as well, now signed
> by the MASA.
>
> > What format are the various bootstrap objects (eg vouchers)? Has
> > anyone built any of these for PoC?
>
> PoC?
Aren't the formats defined in the drafts? E.g., the voucher draft
says it’s a PKCS#7.
Regarding PoC, here's some code to create/validate vouchers:
https://github.com/netconf-wg/zero-touch/tree/master/openssl-test.
K.
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
