Add design note for SUBFLOW encryption

[HiroyasuNishiyama]

This PR adds design note for SUBFLOW encryption.
In some cases, Node-RED users do not want their flows to be looked or manipulated by unauthorized users because of intelectual property or other reasons. This design note aims to address this issue and proposes a flow encryption feature.

[knolleary]

I think we need to be very clear in this design that this is not going to be a feature for all users of Node-RED.

End-to-end encryption of the type described will only be possible where the Node-RED is hosted and the end-user does not have access to the settings file.

Otherwise the end-user will have full access to the decryption scheme/keys and be able to see all of the contents of the flow.

You use base64 as an example - which of course is not encryption. But would it be worthwhile having that as a built-in method that can be used? This raising the question of what the user experience is for creating such a subflow.

• How does the user specify the subflow should be encrypted?
• Are they given a list of available encryption/encoding methods to pick from?
• How does the editor get that list? (I assume it would be added to the /settings endpoint as we do the context stores.)

If we do provide base64 as a built-in option, I can imagine the UI would offer a select box of possible methods such as:

1. JSON
2. base64
3. ... list of methods from the settings file

If that is the way we go, I think it should be labelled as 'encoding' rather than 'encryption'.

Some other thoughts...

• Should we support encryption methods that can take an option key to encrypt the contents?

That would allow me to publicly share a subflow and I get to chose who can import it as they would require me to also give them the decryption key. This is a different use case to the one you've highlighted - it allows for trusted end users to be able to see the internals.

[HiroyasuNishiyama]

This proposal is related to SUBFLOW exporting feature, so the response was very slow. I'm sorry.
It's reasonable that encoding should be used instead of encryption. So, changed the document.
I changed the design note to support NPM packaging, but the packaging UI in Editor is currently undecided, so it is described as future issue and will be updated after fixing it.