docs(day-2): Latest talk

content/_index.md

@@ -9,11 +9,24 @@ This current version is probably full of typos - will fix later. This is what ty
 
 ## How did I get there?
 
-I attended KubeCon + CloudNativeCon Europe 2025 in London.
+I attended Cloud Native Rejekts and KubeCon + CloudNativeCon Europe 2025 in London.
 
 Why? Because learning about all new things in the world of cloud is really important and war stories help to avoid mistakes that other's already made.
 And [last year's experience](https://kubecon24.nicolai-ort.com) was really good, so I wanted to go again.
 
+Plus I actually presented a talk at Cloud Native Rejekts.
+
+## And how does this website get it's content
+
+```mermaid
+graph LR
+    Nicolai<-->|Watches|Talk
+    Nicolai-->|"Takes notes (and typos) + commits"|Repo
+    Repo-->|Triggers|Actions
+    Actions-->|Builds image and pushes to|Registry
+    Kubernetes-->|Pulls latest image|Registry
+```
+
 ## Style Guide
 
 The basic structure is as follows: `day/event-or-session`.

content/day-2/09_e2e-authenticity.md

@@ -0,0 +1,83 @@
+---
+title: End to End Message Authenticity in Cloud Native Systems
+weight: 9
+tags:
+ - rejekts
+ - security
+---
+
+<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
+
+## Why does e2e authenticity matter?
+
+- Classic Setup: Micro-Services with TLS and auth via Bearer
+  ```mermaid
+  graph LR
+      User-->|TLS|Gateway
+      Gateway-->|mTLS|Server
+      Server-->|mTLS|Gateway
+      Gateway-->|TLS|User
+  ```
+- Intrusion: Hacked Gateway
+    - Can modify the request
+    - Could log auth tokens
+    - Could replay requests with different body or token
+
+
+## Baseline OIDC
+- Only IDP has private key for signing
+- Anyone can fetch the private key and verify
+- Usage: SSO, Trust Federation
+- Problem: Symmetric Credential can be forwarded if leaked
+
+## Fixes
+
+### HTTP Message Signatures
+
+- Idea:
+    - Client can sign the content and headers with a symmstric/asynmetric key
+    - Server can verify the signature
+- Implementation: Basicly just an additional Signature Header and a Header that tells us what is included in the signature
+  ```
+  HTTPS POST /test
+  Authorization: Bearer <token>
+  Signature-Input: "authorization" @body
+  Signature: ahsz7d9zahbsdoih
+  ```
+- Problem: Key distribution
+- Real-World: AWS v4 Signature shares accesskey and secretkey out of band and signs header with accesskey (symmatric)
+- Transitive Trust
+
+### OIDC Key binding
+
+TODO: Steal image from slides
+
+### Proof of Posession
+
+> Basicly adds a nonce that we have to sign and the idp now knows that we really posess it
+
+TODO: Steal image from Slides
+
+### OpenPubKey
+
+> Assigns meaning to the nonce and can reconstruct the nonce for a reverse check
+
+## Demo
+
+The demo uses GitHub as a PKI (since all public keys get exposed via github).
+Pretty cool: They automated the demo via a go cli.
+
+TODO: Link to demo code
+TODO: Steal image from Slides
+
+## Next steps
+
+- SPIFFE is the de-facto standard for distributing identities to workloads
+    1. Workloads asks "Who am I"
+    2. Agent attests the workload
+    3. Agent provides OIDC or X.509 to Workloads
+
+* WIMSE RFC: Basicly DPoP/OpenPub
+    1. Workload get's a private key
+    2. Issuer binds workload identity to the public key
+    3. Auth trusts SPIFFE, it can trust the key