Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

> The desire to use SubjectPublicKeyInfo is per tests (2) and (4) described here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_netconf_ysukDdbCA0a70heF1a-5FldZNr4yE&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=2WjGA7HZCdgO3PuNIGcShf2is7JW06LCQdbjHnYFNs8&s=2a467Qepi3ZnOMc6bomXjp3ysTseF0EUXytuahNHZNw&e=>.
>  
> Those experiments do not matter.  TLS sends X509 certificates.  I am not aware of any protocol (and I don’t know all of them, of course) that sends raw public keys.  What protocols are you thinking of?
>  
> If you want to configure an HTTPS server using netconf/yang, you will need to give that server X509 certificates.


The previous line in my response read: "There is a separate field for certificates, which is an X.509 certificate."

So, that need/desire is covered.  Having the "public-key" field is not needed for TLS.



>  No, I was asking if “encrypted private key” is a separate thing from “plaintext private key.”

From a Keystore perspective, there are keys, and each key may either be encrypted or not, but not both at the same time.


Kent // contributor