Northwind Traders हर उस क्रिप्टोग्राफ़िक इस्तेमाल के लिए एक इन्वेंट्री रिकॉर्ड रखती है जो बिज़नेस की सीमा (बाउंड्री) की सुरक्षा करता है, और हर रिकॉर्ड के लिए एक सिस्टम ओनर होता है जो उसके माइग्रेशन पाथ (स्थानांतरण प्रक्रिया) के लिए ज़िम्मेदार होता है। यह रिकॉर्ड प्रोटोकॉल, एल्गोरिदम, सर्टिफ़िकेट, लाइब्रेरी और ओनरशिप के सबूत जैसी जानकारी लेता है, और फिर सर्टिफ़िकेट की सूची के बजाय क्वांटम-कमज़ोर डिपेंडेंसी (निर्भरताओं) का एक ऐसा मैप देता है जिसके आधार पर फ़ैसला लिया जा सके। खतरा यह है कि अभी कस्टमर, पेमेंट और एडमिनिस्ट्रेटिव ट्रैफ़िक को पब्लिक-की क्रिप्टोग्राफ़ी से सुरक्षित किया जाता है, लेकिन भविष्य में क्वांटम कंप्यूटर इसे डिक्रिप्ट (डिकोड) कर सकते हैं; इसलिए अभी डेटा इकट्ठा करके बाद में उसे डिक्रिप्ट करने का जोखिम बना रहता है।
Northwind के ज़रूरी रास्ते कई ट्रस्ट बाउंड्री (भरोसे की सीमाओं) को पार करते हैं। पब्लिक स्टोरफ़्रंट और मोबाइल ऐप EdgeGW तक पहुँचते हैं; EdgeGW म्यूचुअल TLS के साथ Orders को ऑथेंटिकेट करता है; AuthN उन JWTs को साइन करता है जिन्हें एडमिन पोर्टल और API स्वीकार करते हैं; PayBridge पेमेंट प्रोवाइडर तक पहुँचता है; और CI/CD डिप्लॉय करने लायक आर्टिफ़ैक्ट्स को साइन करता है। कॉर्पोरेट और पब्लिक सर्टिफ़िकेट अथॉरिटी अलग-अलग ट्रस्ट रूट बनाती हैं। अगर कोई ऑडिटर किसी एक किनारे (एज) पर RSA-2048 सर्टिफ़िकेट पाता है, तो वह अभी यह नहीं बता सकता कि क्या वही सर्टिफ़िकेट रिलीज़ को साइन करता है, सर्विस को ऑथेंटिकेट करता है या एक्सेस टोकन को वैलिडेट करता है।
यह आर्किटेक्चर कलेक्शन बाउंड्री को तब साफ़ तौर पर दिखाता है जब हम उसे रिकॉर्ड असाइन करते हैं:
यह डायग्राम दिखाता है कि सिर्फ़ सर्टिफ़िकेट इन्वेंट्री क्यों नाकाफ़ी है: TLS, mTLS, JWT वेरिफिकेशन और पैकेज वेरिफिकेशन में पब्लिक-की क्रिप्टोग्राफ़ी अलग-अलग प्रोटोकॉल भूमिकाओं और अलग-अलग मालिकों के साथ काम करती है।
क्योंकि एक ही RSA-2048 की (key) अलग-अलग काम कर सकती है, इसलिए Northwind एक क्रिप्टोग्राफ़िक इस्तेमाल को एक एल्गोरिदम के तौर पर रिकॉर्ड करता है जो एक सीमा पर एक मकसद के लिए काम करता है। TLS सर्वर सर्टिफ़िकेट, ECDH की एक्सचेंज और JWT सिग्नेचर अलग-अलग इस्तेमाल बन जाते हैं, भले ही एक ही प्रोडक्ट उन्हें इस्तेमाल करे। यह अंतर इसलिए ज़रूरी है क्योंकि हाइब्रिड की एस्टैब्लिशमेंट सपोर्टेड TLS पाथ में कॉन्फिडेंशियलिटी एक्सपोज़र को कम कर सकती है, जबकि बिना बदले JWT सिग्नेचर क्वांटम थ्रेट मॉडल के तहत जाली बनाया जा सकता है।
हर रिकॉर्ड बाद में बदलने का फ़ैसला लेने के लिए ज़रूरी सबूत इकट्ठा करता है:
ज़रूरी फ़ील्ड डिस्कवरी और फ़ैसला लेने की प्रक्रिया के बीच अंतर बताते हैं। साइफर-सुइट की जांच से ECDH एक्सपोज़र का पता चलता है, लेकिन लाइब्रेरी वर्शन और बदलाव का तरीका यह तय करते हैं कि क्या EdgeGW हाइब्रिड इम्प्लीमेंटेशन अपना सकता है या नहीं। साइनिंग रिकॉर्ड के लिए वेरिफ़ायर की लोकेशन ज़रूरी होती है, क्योंकि एडमिन पोर्टल, API गेटवे और डिप्लॉयमेंट वेरिफ़ायर को बदले बिना साइनर को बदलने से भरोसा टूटता है। नीचे दी गई तुलना उन छूटी हुई जानकारियों पर गौर करती है जो अक्सर सटीक इन्वेंट्री को रोडमैप बनने से रोकती हैं:
यह टेबल दिखाती है कि एल्गोरिदम का पता लगाना ज़रूरी तो है, लेकिन काफ़ी नहीं है: ओनरशिप, वेरिफ़ायर की पहुँच और प्रोडक्ट वर्शन से यह तय होता है कि क्या कोई स्टैंडर्ड रिप्लेसमेंट असल में लागू किया जा सकता है।
फ़ैसला लेने का नियम बिना मकसद और ओनर वाला रिकॉर्ड किसी आर्टिफ़ैक्ट को बताता है, न कि ऐसी क्रिप्टोग्राफ़िक डिपेंडेंसी को जिसे माइग्रेट किया जा सके।
स्कीमा तय होने के बाद, Northwind उन सीमाओं (boundaries) से शुरुआत करता है जहाँ लंबे समय तक चलने वाला संवेदनशील डेटा होता है या जहाँ इंटीग्रिटी से जुड़े अहम फ़ैसले लागू किए जाते हैं। client→EdgeGW बाहरी TLS को कैप्चर करता है; EdgeGW→Orders अंदरूनी mTLS को कैप्चर करता है; AuthN JWT साइनिंग और हर वेरिफ़ायर को कैप्चर करता है; PayBridge किसी थर्ड-पार्टी डिपेंडेंसी को कैप्चर करता है; और CI/CD आर्टिफ़ैक्ट साइनिंग को कैप्चर करता है। इन्वेंट्री में ECDH को AES से अलग रिकॉर्ड किया जाना चाहिए क्योंकि AES तो शायद सही बना रहे, लेकिन ECDH की-एस्टैब्लिशमेंट के लिए रिप्लेसमेंट या हाइब्रिड ट्रांज़िशन की ज़रूरत पड़ सकती है।
किस एंट्री के लिए साइनर माइग्रेशन और डिस्ट्रिब्यूटेड वेरिफ़ायर की इन्वेंट्री, दोनों की ज़रूरत है: AuthN JWT साइनिंग रिकॉर्ड या EdgeGW→Orders mTLS रिकॉर्ड?
भरी हुई इन्वेंट्री में Northwind की आठ खोजों के लिए सबूत-आधारित रिकॉर्ड का इस्तेमाल किया गया है और नतीजों को RSA-2048, ECDH और ECDSA P-256 एक्सपोज़र के आधार पर ग्रुप किया गया है: