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. কনস্ট্রাক্টর সিগনেচার ​

সব ভাষার ইমপ্লিমেন্টেশন নিচের আর্গুমেন্ট ক্রম ব্যবহার করে।

(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 ধারা ব্যবহার করতে হবে।