> On Nov 30, 2016, at 2:33 PM, Acee Lindem (acee) <a...@cisco.com > <mailto:a...@cisco.com>> wrote: > > > This is something we ran into with ietf-keystore model also. The thoughts are > that key strings should never leave the device. If anything most devices have > tamper proof capability (FIPS 140-2) to wipe the keys out if tampered with or > exported. So exporting the string, encrypted, even with NACM would defy that. > > So, what we have today would with the key strings omitted from the > operational state would be consistent with the direction for the > ietf-keystore model. Correct?
That is correct. Kent can correct me, but we are still trying to figure how to model it in YANG and in the datastores (<applied> and <operational-state>). > > How will this be enforced when we have an applied-config datastore? > > Thanks, > Acee > > > > > > >> On Nov 30, 2016, at 1:37 PM, Acee Lindem (acee) <a...@cisco.com >> <mailto:a...@cisco.com>> wrote: >> >> In the days of MIBs, we used to omit key strings from the data that would be >> returned. This was ostensibly done for security purposes. We did the same >> for the operational state returned for keystring in key-chain-entries. I’m >> now thinking this was a mistake. Rather, it would seem that one could use >> RFC 6536 rules to accomplish this at a more granular level. >> >> Note that the model also support keystring encryption as described in RFC >> 5649. >> >> Thanks, >> Acee >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org <mailto:netmod@ietf.org> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > > > Mahesh Jethanandani mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
