You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Precise security properties that something like ML-KEM has or doesn't have. This is documented in eprint papers, and you expect to encounter terms like "IND-CCA2" or "MAL-BIND-PK".
Complete cryptographic protocols that can be directly turned into software, such as how to use TLS with ML-KEM.
Deirdre and Joe Salowey advocated that there is a documentation gap in between these two things that pqc-for-engineers should fill. This would make our target audience, essentially, IETF protocol designers, or IETF-adjacent protocol designers (ie people who maintain bespoke crypto things).
Tim and Mike advocated that pqc-for-engineers should target the knowledge gap above this; ie the people who deploy TLS, who have to choose configuration settings for TLS, issue certs for TLS, choose hardware vendors for TLS, etc.
I think we need to choose. I think that (as Ben S pointed out in chat), if this draft attempts to do both, it will end up being XKCD 2501 and it will alienate most of its target audience by being too dense and jargony (unless we very carefully separate out sections).
The text was updated successfully, but these errors were encountered:
ounsworth
changed the title
What is our target audience
What is our target audience?
Nov 7, 2024
We had this discussion at PQUIP 121. Summary:
Things that are well documented:
Deirdre and Joe Salowey advocated that there is a documentation gap in between these two things that pqc-for-engineers should fill. This would make our target audience, essentially, IETF protocol designers, or IETF-adjacent protocol designers (ie people who maintain bespoke crypto things).
Tim and Mike advocated that pqc-for-engineers should target the knowledge gap above this; ie the people who deploy TLS, who have to choose configuration settings for TLS, issue certs for TLS, choose hardware vendors for TLS, etc.
I think we need to choose. I think that (as Ben S pointed out in chat), if this draft attempts to do both, it will end up being XKCD 2501 and it will alienate most of its target audience by being too dense and jargony (unless we very carefully separate out sections).
The text was updated successfully, but these errors were encountered: