Re: [netconf] ietf-crypto-types: read-only nodes to provide fingerprints of public keys and certificates

["[e-mail]" <[e-mail]>]

-----Original Message-----
From: Kent Watsen <[e-mail]>
Sent: Dienstag, 17. März 2020 22:52
To: Angermann, Maurice (DI PA CI R&D 2) <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] ietf-crypto-types: read-only nodes to provide fingerprints of public keys and certificates

Hi Kent,

> Hi Maurice,
> > I would like to make a suggestion regarding the groupings for public keys and certificates in draft-ietf-netconf-crypto-types-14:
> >
> > Especially in case of manual server verification in applications like (Open)SSH or HTTPS (self-signed certs), it is quite common to compare fingerprints of an (remote) identity.
> > Therefore it might be useful to add operational data (“config false”) nodes to those groupings to provide the fingerprints of a public key/certificate.
>
> If I understand you correctly, you're describing a use case whereby a server is configured to listen for SSH and/or TLS connections, and the administrator of the server wishes to communicate the “fingerprint” value to clients that they should accept when establishing a connection to the server for the first time, as opposed to blindly accepting the presented fingerprint (i.e., the "trust on first use” problem).  Is this correct?

Yes, that could be one use case, but I agree with what you have mentioned in 1) below: In this case it would be to be preferred to send the whole public key or certificate.
But this is not necessarily about an administrator communicating the fingerprints to clients.

This might also be one administrator who wants to verify the certificate of an HTTPS server displayed by the client-side web browser.
I don't know if there is a web browser that supports to display the server's certificate (chain) as CMS structure, but web browsers display SHA1/SHA256 fingerprints.
The administrator could then access the operational datastore first through a "trusted" connection to get the fingerprint.
For instance, this could be a direct serial connection/console port, or a previously verified NETCONF/SSH connection.

Otherwise, in order to verify the certificate without fingerprints available, one would have to manually follow steps like the following.
Lets call this A):
- In the browser, export the certificate to a file.
- (If a certificate chain is used, additional intermediate/CA certificates would have to be exported as well)
- Create a CMS structure from the exported certificate file(s).
- Now he or she could start to compare the locally created CMS with the CMS stored in <running>.

Please correct me in case I have missed an easier way to do that.

Similar steps are required if an administrator wants to manually check fingerprints of a certificate chain in <running>, e.g. configured by a different administrator as a trust-anchor.
Lets call this B):
- Read the CMS from <running>
- Split the CMS to single X509 certs
- Create fingerprint per X509 cert

Thinking about these scenarios, I have noticed that the proposal I have sent wouldn't cover the case that one single CMS structure contains more than one certificate.
I will update it accordingly.

// <-- OT -->
BTW: In the NETCONF WG mail archive I have found the following question in a message from June 2019:
"Would it help if the crypto-types draft included an Appendix section to supply the `openssl` commands for just the 'trust-anchor-cert-cms' and 'end-entity-cert-cms' typedefs?"
(https://mailarchive.ietf.org/arch/msg/netconf/_CN84eZIZH1enQtI3DgZa-Xh4XI/)

I agree with Juergen, that it would be useful to have such an appendix.
Are there still plans to add it?
I only know "openssl crl2pkcs7" to create a PKCS7 structure with one or more PEM certs, but how can "openssl" be used to do the same for CMS?
// <-- OT -->



> Assuming this is the use case, some questions are:
>
> 1) why would’nt the administrator send the server’s entire public-key/certificate instead of a fingerprint?
>
> 2) do TLS-based applications ever use fingerprints, as opposed to the Issue’s cert, even if a certificate is self-signed?
>
> Assuming fingerprints are indeed needed/used:
>
> 3) is there a standard fingerprint formats to use, or does each app (e.g., OpenSSL) define its own?
>
> 4) instead of the administrator obtaining the fingerprint via operational state (config false) data, would it be just as well for them to connect to the server itself and get the value that way?
>
>
> Kent // as a contributor

To 1): Absolutely, in the case of an administrator deploying certificates e.g. via email, that would be the better approach.

To 2): I think TLS-based applications should "internally" never use fingerprints. Please note that this proposal is primarily meant to simplify manual verifications, since TLS-based applications like web browser usually display fingerprints to the user instead of e.g. a PEM-encoded certificate or even a CMS structure.

To 3)
This is a very good question.

At least for X509 certificate fingerprints it is common to hash the DER-encoded representation. Unfortunately I haven't found this described as an official standardized approach.

But I'm afraid that for SSH public keys there is not such a de-facto standard.
I think OpenSSH-like formats as created by "ssh-keygen" might be most common.
So assuming fingerprints are also added to public keys in crypto-types, I think a YANG feature could give an implementation the choice to specify whether it supports OpenSSH-like fingerprints or not.

To 4) Should be the same use case as described in A).


Maurice



> > That would provide easy manual verification, e.g. of a whole certificate chain stored in <running>.
> >
> > Any feedback on this proposal is much appreciated.
> >
> > Please find an example of how a generic realization in the crypto-types module could look like below:
> >
> > Since “x509c2n:tls-fingerprint” is probably not an appropriate namespace to describe a public-key fingerprint, an according datatype could look like that:
> >   typedef fingerprint {
> >     type yang:hex-string {
> >       /* max string range of x509c2n:tls-fingerprint's pattern restriction */
> >       length "min .. 764";
> >     }
> >   }
> >
> > A new grouping to provide fingerprints depending on the available hashing algorithms:
> >   grouping fingerprints-grouping {
> >     description
> >       "A set of fingerprints of a public key or a certificate.
> >        Implementations SHOULD NOT provide a list entry for an algorithm
> >        that is not being listed as supported in iana-hash-algs.";
> >    container fingerprints {
> >       description
> >         "A set of fingerprints of a public key or a certificate.";
> >       list fingerprint {
> >         key "algorithm";
> >         description
> >           "A fingerprint.";
> >         leaf algorithm {
> >           type iha:hash-algorithm-type;
> >           description
> >             "The hashing algorithm.";
> >         }
> >         leaf hash {
> >           type fingerprint;
> >           description
> >             "The fingerprint value.";
> >         }
> >       }
> >     }
> >   }
> >
> > The resulting updated groupings would look like that: (*) indicates the new nodes
> >   grouping public-key-grouping
> >     +-- algorithm                 iasa:asymmetric-algorithm-type
> >  (*)+--ro fingerprints
> >  (*)|  +--ro fingerprint* [algorithm]
> >  (*)|     +--ro algorithm             iha:hash-algorithm-type
> >  (*)|     +--ro hash                  fingerprint
> >     +-- public-key-format?        identityref
> >     +-- public-key                binary
> >
> >   grouping trust-anchor-cert-grouping
> >     +-- cert?                     trust-anchor-cert-cms
> >  (*)+--ro fingerprints
> >  (*)|  +--ro fingerprint* [algorithm]
> >  (*)|     +--ro algorithm             iha:hash-algorithm-type
> >  (*)|     +--ro hash                  fingerprint
> >     +---n certificate-expiration
> >        +-- expiration-date    yang:date-and-time
> >
> >   grouping end-entity-cert-grouping
> >     +-- cert?                     end-entity-cert-cms
> >  (*)+--ro fingerprints
> >  (*)|  +--ro fingerprint* [algorithm]
> >  (*)|     +--ro algorithm             iha:hash-algorithm-type
> >  (*)|     +--ro hash                  fingerprint
> >     +---n certificate-expiration
> >        +-- expiration-date    yang:date-and-time
> >
> > Please note that leaf-lists as used in “trust-anchor-certs-grouping” or “end-entity-certs-grouping” wouldn’t be considered by that approach.
> >
> > Again, any feedback is appreciated.
> >
> > Thanks
> > BR Maurice
> >
> >
> >
> > With best regards,
> > Maurice Angermann
> >
> > Siemens AG
> > Digital Industries
> > Process Automation
> > Software House Khe
> > DI PA CI R&D 2
> > Oestliche Rheinbrueckenstr. 50
> > 76187 Karlsruhe, Germany
> > mailto:[e-mail]
> > www.siemens.com/ingenuityforlife
> >
> > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
> >
> >
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf