Re: [netconf] crypto-types fallback strategy

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> 
> > On Sep 19, 2019, at 6:53 AM, Martin Bjorklund <[e-mail]> wrote:
> > 
> > Here's a link to the discussion we had some five years ago:
> > 
> > https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs
> > <https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs>
> 
> 
> So apropos.    Yeah for email archives!
> 
> I noticed a discrepancy between the file format described in RFC 4716
> and the one `ssh-keygen` produces by default.  In order to get the
> standard public key file format, I had to use the command `ssh-keygen
> -e -m RFC4716 -f <public-or-private-key-file>`.
> 
> We can define a type for this:
> 
> 	typedef rfc4716-string {
> 	    type string;
> 	    description
> 	      "A string containing the contents of the file described by RFC
> 	      4716";
> 	    reference
> 	      "RFC 4716: The Secure Shell (SSH) Public Key File Format";
> 	}
> 
> And perhaps another for PEMs:
> 
> 	typedef pem-string {
> 	    type string;
> 	    description
> 	      "A string containing the PEM encoding of an ASN.1 structure.";
> 	    reference
> 	      "TBD";
> 	}
> 
> And then put a union into the "public-key" leaf:
> 
>     leaf public-key {
>       nacm:default-deny-write;
>       type union {
>           type rfc4716-string;
>           type pem-string;
>           type binary;
>       }
>       mandatory true;
>       description
>         "The value of the public key.  The interpretation of this value is
>          defined by 'algorithm'.  For example, algorithms using SSH
>          specific identities always use 'rfc4716-string', where algorithms
>          using X.509 specific identities encode a SubjectPublicKeyInfo
>          (RFC 5280) that may be a 'binary' (for DER encodings) or 
>          'pem-string' (for PEM encodings).";
>       reference
>         "RFC 5280: Internet X.509 Public Key Infrastructure Certificate
>                             and Certificate Revocation List (CRL) Profile";
>     }
> 
> 
> And similar for the private key?
> 
> AFAICT, that all are effectively strings doesn't matter.
> Implementations can try to parse the options until something works.
> 
> 
> Thoughts?

What's wrong with the definition we use in RFC 7317?


/martin