On 08/25/2017 09:36 AM, Kent Watsen wrote:
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.
Please read:
https://mta.openssl.org/pipermail/openssl-users/2017-August/006374.html
VIktor gives his views of what works in the field. I have found Viktor
to be a great help, and tends to really know what works. Besides on the
openssl-user list, he is on the postfix-user list.
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.
Most systems running netconf have the storage capacity for this. I
would think.
In my auto meetings, many of the devices they are discussing do not have
this option.
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.
I think PKCS is mentioned twice in the bootstrap draft. Nothing about
iDevID format, for example. 802.1AR does not say anything about iDevID
(or lDevID) format.
Regarding PoC, here's some code to create/validate vouchers:
https://github.com/netconf-wg/zero-touch/tree/master/openssl-test.
For next week.
Bob
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
