Re: [Cfrg] Outline -> was Re: normative references

[Paul Lambert <[e-mail]>]

⨳|The key exchange and PKIX we have now works with this restriction just
 ⨳|fine. [ ⨳] 

PKIX does not work well ... and it will not be used for my applications.
When was the last time you used a PKI based key to encrypt something?

I'm building consumer equipment that needs a simple enrollment and trust model.  We will have public keys embedded in a wide range of devices (large and small).  The enrollment process may include the presentation of a public key in machine readable form (e.g. QR code). Smaller is better.  PKI and any naming hierarchy is an unnecessary burden.  Human validation of visual information is a fall-back for the device introduction process.

Initial setup is Static and/or ephemeral DH based, signatures later required. 


[ ⨳] >The naive solution I mentioned above doesn't require any extra
 ⨳|rounds, just some more data. Yes, it is sort of a pain in highly
 ⨳|restricted environments, but I'm having trouble thinking of a highly
 ⨳|restricted environment with lots of public key ops taking place that
 ⨳|need those semantics.
[ ⨳] 
It's not the size restriction or speed that is an issue. I'm looking at making the 'trust chain' simpler.  It is not a critical mechanism ... but it would make the overall presentation of chains of related keys easier.  

Signature authenticated DH is an extra couple of steps but is viable. Key 'trust statements' just require an extra level of abstraction.

Will be proceeding with a multi key model ... unless I can find a well vetted single key algorithm suite.  That's why I'm asking here....   


Paul

 ⨳|It's never going to amount to a high percentage of the load anyway.
 ⨳|>
 ⨳|> Thanks,
 ⨳|>
 ⨳|> Paul
 ⨳|
 ⨳|Sincerely,
 ⨳|Watson
 ⨳|>
 ⨳|>
 ⨳|
 ⨳|
 ⨳|
 ⨳|--
 ⨳|"Those who would give up Essential Liberty to purchase a little
 ⨳|Temporary Safety deserve neither  Liberty nor Safety."
 ⨳|-- Benjamin Franklin