DAT سرٹیفکیٹ ​

1. جائزہ ​

DAT سرٹیفکیٹ ایک ایسی وضاحت ہے جو DAT کے اجراء کے اختیار کو کنٹرول کرتی ہے اور ٹوکن کے دستخط و انکرپشن الگورتھم اور کی (Key) کی معلومات کا انتظام کرتی ہے۔

ہر سرٹیفکیٹ کا ایک منفرد ID (CID) ہوتا ہے، اور یہ DAT کے اجراء کی ممکنہ مدت اور تیار ہونے والے ٹوکن کی میعاد (TTL) کو لازمی قرار دے کر ٹوکن کے لائف سائیکل کو محفوظ طریقے سے منظم کرتا ہے۔

DAT میں کی رولنگ اختیاری نہیں ہے۔ سرٹیفکیٹ میں اجراء کی ممکنہ مدت وضاحت کی سطح پر طے شدہ ہوتی ہے، اس لیے وہ مدت گزر جانے کے بعد اس سرٹیفکیٹ سے نئے ٹوکن نہیں بنائے جا سکتے۔

2. سرٹیفکیٹ کا ڈھانچہ ​

cid . start . duration . ttl . sig-alg . crypto-alg . sig-key . crypto-key

2.1. فیلڈ کی تفصیلی وضاحت ​

CID : Hex (uint64)

• سرٹیفکیٹ کی شناخت کرنے والا منفرد سرٹیفکیٹ ID ہے۔ یہ DAT کے CID فیلڈ سے میپ ہوتا ہے اور تصدیق کے وقت طے کرتا ہے کہ کون سا سرٹیفکیٹ استعمال کیا جائے۔
• CID ایک ناقابلِ تبدیل شناخت کنندہ ہے۔ کی تبدیل کرتے وقت وہی CID دوبارہ استعمال نہیں کیا جاتا بلکہ نئے CID کے ساتھ سرٹیفکیٹ جاری کیا جاتا ہے۔

DAT اجراء شروع ہونے کا وقت : uint64 (Unix Time)

• اس سرٹیفکیٹ کو استعمال کرتے ہوئے DAT جاری کیے جانے کا آغاز وقت سیکنڈز (Seconds) کی اکائی میں ظاہر کرتا ہے۔

DAT اجراء کی مدت : uint64 (Seconds)

• سرٹیفکیٹ کی اجراء کی مدت ہے۔ DAT اجراء شروع ہونے کا وقت سے یہ مدت (سیکنڈ) گزر جانے کے بعد اس سرٹیفکیٹ سے نئے DAT جاری نہیں کیے جا سکتے۔
• یہ مطلق وقت نہیں بلکہ ایک مدت (duration) ہے۔ اختتامی وقت start + duration سے شمار کیا جاتا ہے۔

DAT TTL (درستگی کا وقت) : uint64 (Seconds)

• اس سرٹیفکیٹ سے جاری ہونے والے DAT کی میعاد (Time To Live) ہے۔ DAT بناتے وقت expire کی قدر اجراء کے وقت میں یہ قدر جوڑ کر مقرر کی جاتی ہے۔

دستخط الگورتھم : String / Enum

• DAT کے signature فیلڈ کو تیار کرنے اور تصدیق کرنے کے لیے استعمال ہونے والا دستخط الگورتھم ہے۔

خفیہ کاری الگورتھم : String / Enum

• DAT کے secure فیلڈ کو خفیہ کرنے اور ڈی کرپٹ کرنے کے لیے استعمال ہونے والا انکرپشن الگورتھم ہے۔

دستخط کی چابی : Base64Url (Binary)

• دستخط اور تصدیق میں استعمال ہونے والا کلیدی ڈیٹا ہے۔ (الگورتھم کے مطابق یہ اے سیمٹرک کی کی Public/Private Key یا سیمٹرک کی ہو سکتی ہے۔)

خفیہ کاری کی چابی : Base64Url (Binary)

• secure فیلڈ کی انکرپشن اور ڈی کرپشن میں استعمال ہونے والا انکرپشن کلیدی ڈیٹا ہے۔

2.2. وقت کا حساب ​

end    = start + duration        اجراء کے اختتام کا وقت
expire = end + ttl               سرٹیفکیٹ کی حتمی میعاد ختم ہونے کا وقت

• تمام حسابات uint64 میں کیے جاتے ہیں اور صرف اوور فلو کو خرابی کے طور پر مسترد کیا جاتا ہے۔
• duration = 0 اور ttl = 0 جائز قدریں ہیں۔ ان سے ایسا سرٹیفکیٹ ظاہر کیا جا سکتا ہے جس کی اجراء کی کھڑکی فوراً بند ہو جائے، یا ایسا سرٹیفکیٹ جو ایسا ٹوکن بنائے جو میعاد کے ساتھ ہی غیر مؤثر ہو جائے۔
• تمام فیلڈز بغیر علامت کے اعداد صحیح ہیں، اس لیے منفی قدریں ٹائپ کی سطح پر موجود ہی نہیں ہیں۔

2.3. کنسٹرکٹر سگنیچر ​

تمام زبانوں کے نفاذات نیچے دی گئی دلائل (arguments) کی ترتیب استعمال کرتے ہیں۔

(cid, dat_issuance_start_seconds, dat_issuance_duration_seconds, dat_ttl_seconds,
 signature_key, crypto_key)

3. سرٹیفکیٹ کا لائف سائیکل ​

• اجراء کی اہلیت کا فیصلہ signable() && start <= now <= end سے ہوتا ہے، اور دونوں سرے شامل ہیں۔
• اجراء کی کھڑکی بند ہونے کے بعد بھی سرٹیفکیٹ مزید ttl کے برابر زندہ رہتا ہے، کیونکہ کھڑکی بند ہونے سے عین پہلے جاری ہونے والا ٹوکن اپنی پوری عمر مکمل کر سکنا چاہیے۔
• اجراء کی تاخیر (delay) کا مرحلہ اس لیے ہے تاکہ کلسٹر کے تمام نوڈز کو نیا سرٹیفکیٹ حاصل کرنے کا وقت مل جائے۔ تفصیل کے لیے CMS ہم آہنگی دستاویز دیکھیں۔

4. الگورتھمز ​

4.1. دستخط الگورتھم ​

DAT کی جعلسازی اور تبدیلی سے بچاؤ کے لیے دستخط الگورتھمز کی فہرست۔ سیمٹرک اور اے سیمٹرک، دونوں طریقے سپورٹ کیے جاتے ہیں۔

MFS (Maximum Fixed Secret): ہیش الگورتھم کے آؤٹ پٹ (Output) کے سائز کے برابر بٹس کی مقررہ سائز خفیہ کی استعمال کرنے کا طریقہ ہے۔

4.2. انکرپشن الگورتھم ​

DAT کے اندر خفیہ ڈیٹا (secure فیلڈ) کی حفاظت کے لیے تصدیق شدہ انکرپشن (Authenticated Encryption) الگورتھمز کی فہرست۔

IV (Initialization Vector) کی اندرونی شمولیت: ہر انکرپشن پر تیار ہونے والا منفرد 96-بٹ NONCE (IV) انکرپشن کے نتیجے سے پہلے سابقہ (Prefix) کی شکل میں جوڑ دیا جاتا ہے۔ ڈی کرپشن کے وقت پہلے 96 بٹس کو IV کے طور پر الگ کر کے ڈی کرپشن کی جاتی ہے۔

4.3. کی کی لمبائی کی تصدیق ​

سرٹیفکیٹ پڑھتے وقت یہ جانچا جاتا ہے کہ اعلان کردہ الگورتھم کی بٹ تعداد اور اصل کی کی لمبائی آپس میں مطابقت رکھتی ہے یا نہیں۔

مثال کے طور پر اگر IV-AES256-GCM کے اعلان والے سرٹیفکیٹ میں 16 بائٹ کی موجود ہو تو امپورٹ ہی مسترد کر دیا جاتا ہے۔ اس جانچ کے بغیر یہ سمجھتے ہوئے کہ AES-256 استعمال ہو رہا ہے، عملاً AES-128 پر کام ہوتا رہے گا۔

5. verify-only ایکسپورٹ ​

جو سرورز صرف تصدیق کرتے ہیں، انہیں دستخط کے لیے پرائیویٹ کی دینے کی ضرورت نہیں۔ DAT سرٹیفکیٹ اسی مقصد کے لیے verify-only ایکسپورٹ فراہم کرتا ہے۔

HMAC ایک سیمٹرک کی ہے، اس لیے "صرف تصدیق کے قابل کی" جیسی کوئی چیز موجود نہیں۔ لہٰذا verify-only ایکسپورٹ کی کوشش خاموشی سے نظر انداز نہیں کی جاتی بلکہ فوراً خرابی کے طور پر مطلع کی جاتی ہے۔ اگر HMAC سرٹیفکیٹس شامل ہوں تو verify-only ایکسپورٹ کی کال ناکام ہو جائے گی، اس لیے صرف تصدیق کرنے والے نوڈز چلانے کی صورت میں ECDSA خاندان استعمال کرنا چاہیے۔