S/MIME सर्टिफ़िकेट प्रोफ़ाइलें

इस लेख में उन ज़रूरी शर्तों के बारे में बताया गया है जिन्हें X.509 चेन में मौजूद हर सर्टिफ़िकेट को पूरा करना होता है. ऐसा इसलिए, ताकि एन्क्रिप्ट (सुरक्षित) किए गए या S/MIME से हस्ताक्षर किए गए ईमेल के साथ इस्तेमाल करने के लिए, उस पर भरोसा किया जा सके.

इन ज़रूरी शर्तों के अलावा, चेन को किसी ऐसी सर्टिफ़िकेट अथॉरिटी (सीए) के सर्टिफ़िकेट से जोड़ना होगा जिस पर Google इस मकसद के लिए साफ़ तौर पर भरोसा करता हो. आपके पास उन सीए से रूट सर्टिफ़िकेट स्वीकार करने का विकल्प भी होता है जिन पर आपको भरोसा है. ज़्यादा जानकारी के लिए, रूट सर्टिफ़िकेट के दिशा-निर्देश पर जाएं.

ध्यान दें:

  • Google, S/MIME के लिए CA सर्टिफ़िकेट की एक सूची उपलब्ध कराता है और उसे अपडेट करता रहता है. Gmail, इस सूची में शामिल सर्टिफ़िकेट पर भरोसा करता है. Google, सीए की सूची को अपनी सूझ-बूझ से भरोसेमंद मानता है. Google के पास बिना सूचना दिए, किसी भी समय रूट सीए को हटाने का अधिकार है.
  • पक्का करें कि इंस्टॉल किए गए एक्सटेंशन, एक ही सर्टिफ़िकेट में मौजूद अन्य एक्सटेंशन के साथ मेल खाते हों. उदाहरण के लिए, अगर nsCertTypes तय किए गए हैं, तो उन्हें ठीक उसी तरह के इस्तेमाल को कवर करना होगा जिस तरह से key usage extension, extended key usage extension, और basic constraints extension करते हैं.

सर्टिफ़िकेट चेन के नियम

रूट सीए

फ़ील्ड मान

जारी करने वाले का डीएन

इसमें सीए की पहचान होनी चाहिए.

उदाहरण के लिए, डीएन कोई सामान्य वैल्यू नहीं होनी चाहिए, जैसे कि "सर्टिफ़िकेट अथॉरिटी."

सर्टिफिकेट का विषय

कोड में बदला गया फ़ॉर्म, बाइट-फ़ॉर-बाइट के हिसाब से, जारी करने वाले के DN से मेल खाना चाहिए.

सब्जेक्ट पब्लिक की इंफ़ो

2048, 3072 या 4096 के आरएसए मॉडुलस के साथ rsaEncryption. इसके अलावा, secp256r1 या secp384r1 का इस्तेमाल करके ecPublicKey.

इंटरमीडिएट सीए सर्टिफ़िकेट, जो सर्टिफ़िकेट जारी करने वाले इंटरमीडिएट सीए के अलावा किसी और इंटरमीडिएट सीए से मिले हों

अगर रूट और एंड एंटिटी के बीच एक से ज़्यादा इंटरमीडिएट सीए हैं, तो इस जानकारी का इस्तेमाल करें. ये इंटरमीडिएट सीए, सीधे तौर पर या किसी और तरीके से जुड़े हो सकते हैं.

सर्टिफ़िकेट जारी करने वाला इंटरमीडिएट सीए, वह इंटरमीडिएट सीए होता है जो एंड एंटिटी सर्टिफ़िकेट जारी करता है. यह सेक्शन, चेन में मौजूद किसी भी इंटरमीडियरी सीए पर लागू होता है. हालांकि, यह सेक्शन उस इंटरमीडियरी सीए पर लागू नहीं होता है जिसने सर्टिफ़िकेट जारी किया है.

फ़ील्ड मान
वर्शन वर्ज़न 3
क्रम संख्या यह वैल्यू, शून्य से ज़्यादा होनी चाहिए. INTEGER के तौर पर DER कोड में बदलने पर, यह 20 बाइट से कम या इसके बराबर होना चाहिए.
हस्ताक्षर एल्गोरिदम RSA के साथ SHA‐256, SHA‐384 या SHA‐512. या SHA‐256, SHA‐384 या SHA‐512 के साथ ECDSA
जारी करने वाले का डीएन

यह जारी करने वाले CA के Subject DN से पूरी तरह मेल खाना चाहिए.
मान्य रहने की अवधि कोई शर्त नहीं
सर्टिफिकेट का विषय कोई शर्त नहीं
सब्जेक्ट पब्लिक की इंफ़ो

2048, 3072 या 4096 के आरएसए मॉडुलस के साथ rsaEncryption. इसके अलावा, secp256r1 या secp384r1 का इस्तेमाल करके ecPublicKey
एक्सटेंशन उपलब्धता सबसे अहम सिद्धांत वैल्यू
कुंजी का इस्तेमाल ज़रूरी है हां

इनके लिए बिट पोज़िशन सेट होनी चाहिए: keyCertSign
अन्य बिट पोज़िशन सेट की जा सकती हैं
बुनियादी पाबंदियां ज़रूरी है हां cA फ़ील्ड को true पर सेट करना ज़रूरी है
pathLenConstraint फ़ील्ड मौजूद होना चाहिए
सीआरएल डिस्ट्रिब्यूशन पॉइंट ज़रूरी है नहीं

कम से कम एक ऐसा एचटीटीपी
यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर मौजूद होना चाहिए जिसे कोई भी ऐक्सेस कर सके
(ध्यान दें) सर्टिफ़िकेट रद्द करने वाले सर्वर को, CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates के इन सेक्शन का पालन करना होगा. यह नीति, वर्शन 1.3.2 या इससे नए वर्शन की होनी चाहिए:
  • 4.9.7. सीआरएल जारी करने की फ़्रीक्वेंसी
  • 4.9.9. सर्टिफ़िकेट निरस्त करने/स्थिति की जांच करने की ऑनलाइन सुविधा की उपलब्धता

  • 4.9.10. ऑनलाइन रद्द करने की जांच से जुड़ी ज़रूरी शर्तें
    4.10.2 सेवा की उपलब्धता
कोई अन्य एक्सटेंशन मौजूद हो सकता है

इंटरमीडिएट सीए सर्टिफ़िकेट, जो एंड एंटिटी जारी करता है

अहम जानकारी: चेन में कम से कम एक इंटरमीडिएट सीए सर्टिफ़िकेट ज़रूर होना चाहिए. इसका मतलब है कि रूट सीधे तौर पर डिजिटल तौर पर साइन किए गए सर्टिफ़िकेट जारी नहीं कर सकता.

फ़ील्ड मान
वर्शन वर्ज़न 3
क्रम संख्या यह शून्य (0) से ज़्यादा होना चाहिए. साथ ही, DER के तौर पर INTEGER में कोड किए जाने पर, यह 20 बाइट से कम या इसके बराबर होना चाहिए.
हस्ताक्षर एल्गोरिदम

RSA के साथ SHA‐256, SHA‐384 या SHA‐512. इसके अलावा, SHA‐256, SHA‐384 या SHA‐512 के साथ ईसीडीएसए का इस्तेमाल किया जा सकता है.
जारी करने वाले का डीएन

यह जारी करने वाले CA के Subject DN से पूरी तरह मेल खाना चाहिए.
मान्य रहने की अवधि

notBefore और notAfter के बीच अंतर

यह 10 साल से ज़्यादा नहीं होना चाहिए और 20 साल से ज़्यादा नहीं होना चाहिए.
सर्टिफिकेट का विषय

इसमें सीए के इस्तेमाल के बारे में बताया जाना चाहिए.
सब्जेक्ट पब्लिक की इंफ़ो

2048, 3072 या 4096 के आरएसए मॉडुलस के साथ rsaEncryption. इसके अलावा, secp256r1 या secp384r1 का इस्तेमाल करके ecPublicKey
एक्सटेंशन उपलब्धता सबसे अहम सिद्धांत वैल्यू
कुंजी का इस्तेमाल ज़रूरी है हां

इनके लिए बिट पोज़िशन सेट होनी चाहिए:
keyCertSign
इनके लिए बिट पोज़िशन सेट की जा सकती है:
cRLSign
digitalSignature
अगर इसका इस्तेमाल सीधे तौर पर OCSP जवाबों पर हस्ताक्षर करने के लिए किया जाता है, तो यह मौजूद होना चाहिए:
digitalSignature

अन्य बिट पोज़िशन सेट नहीं होनी चाहिए
एक्सटेंडेड की यूसेज ज़रूरी है कोई एक ये मौजूद होने चाहिए:
emailProtection
ये मौजूद नहीं होने चाहिए:
serverAuth
codeSigning
timeStamping
anyExtendedKeyUsage

बुनियादी पाबंदियां

 ज़रूरी है हां

cA फ़ील्ड को true पर सेट करना ज़रूरी है
pathLenConstraint फ़ील्ड मौजूद होना चाहिए और इसकी वैल्यू 0 होनी चाहिए
सर्टिफ़िकेट की नीतियां वैकल्पिक नहीं

एक policyIdentifier दिया जाना चाहिए, जो उस नीति की पहचान करता हो जिसके तहत सीए काम करता है. साथ ही, यह anyPolicy नहीं होना चाहिए.
अगर cps मौजूद है, तो उसमें मान्य एचटीटीपी या एचटीटीपीएस लिंक होना चाहिए.
सीआरएल डिस्ट्रिब्यूशन पॉइंट ज़रूरी है नहीं

कम से कम एक ऐसा एचटीटीपी
यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर मौजूद होना चाहिए जिसे कोई भी ऐक्सेस कर सके.
(ध्यान दें)

सर्टिफ़िकेट रद्द करने वाले सर्वर को, CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates के वर्शन 1.3.2 या इसके बाद के वर्शन के इन सेक्शन के मुताबिक काम करना चाहिए:

  • 4.9.7. सीआरएल जारी करने की फ़्रीक्वेंसी
  • 4.9.9. सर्टिफ़िकेट निरस्त करने/स्थिति की जांच करने की ऑनलाइन सुविधा की उपलब्धता
  • 4.9.10. ऑनलाइन निरस्तीकरण की जांच करने की ज़रूरी शर्तें
  • 4.10.2. सेवा की उपलब्धता
कोई अन्य एक्सटेंशन वैकल्पिक नहीं

यह मौजूद हो सकता है.

एंड-इकाई का सर्टिफ़िकेट

फ़ील्ड मान
वर्शन वर्ज़न 3
क्रम संख्या

यह शून्य (0) से ज़्यादा होना चाहिए. साथ ही, इसमें कम से कम 64 बिट होने चाहिए, ताकि इसका अनुमान न लगाया जा सके.

ध्यान दें: इसे CA/Browser Forum Baseline Requirements Certificate Policy के एंड एंटिटी सीरियल नंबर के एन्ट्रॉपी से जुड़ी ज़रूरी शर्तों को दिखाने के लिए अपडेट किया जाएगा.
हस्ताक्षर एल्गोरिदम RSA के साथ SHA‐256, SHA‐384 या SHA‐512. इसके अलावा, SHA‐256, SHA‐384 या SHA‐512 के साथ ईसीडीएसए का इस्तेमाल किया जा सकता है.
जारी करने वाले का डीएन

यह जारी करने वाले CA के Subject DN से पूरी तरह मेल खाना चाहिए.
मान्य रहने की अवधि

notBefore और notAfter के बीच का अंतर 27 महीनों से ज़्यादा नहीं होना चाहिए.

notBefore का समय, हस्ताक्षर किए जाने के समय से 48 घंटे पहले या बाद का होना चाहिए.
सर्टिफिकेट का विषय

ईमेल पते के अलावा, विषय से जुड़े किसी भी अन्य खास नाम की पुष्टि, प्रमाणपत्र जारी करने से पहले अच्छी तरह से की जानी चाहिए. इसके लिए, सार्वजनिक तौर पर उपलब्ध और ऑडिट की गई प्रक्रिया का इस्तेमाल किया जाना चाहिए. स्वीकार्य प्रक्रिया के लिए, CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates के सेक्शन 3.2.3 "Authentication of Individual Identity" का वर्शन 1.3.2 या इससे नया वर्शन देखें.

कोई भी ईमेल पता (उदाहरण के लिए, commonName या emailAddress फ़ील्ड में) भी Subject Alternate Name एक्सटेंशन में rfc822Name के तौर पर मौजूद होना चाहिए.
सब्जेक्ट पब्लिक की इंफ़ो

2048, 3072 या 4096 के आरएसए मॉडुलस के साथ rsaEncryption. इसके अलावा, secp256r1 या secp384r1 का इस्तेमाल करके ecPublicKey
एक्सटेंशन उपलब्धता सबसे अहम सिद्धांत वैल्यू
कुंजी का इस्तेमाल (आरएसए) ज़रूरी है हां

बिट पोज़िशन को इनमें से किसी एक के लिए सेट किया जाना चाहिए:
digitalSignature
और/या
nonRepudiation/contentCommitment
बिट पोज़िशन को इनके लिए सेट किया जा सकता है:
dataEncipherment
keyEncipherment

अन्य बिट पोज़िशन सेट नहीं होनी चाहिए.
कुंजी का इस्तेमाल (ईसीडीएच) ज़रूरी है

बिट की पोज़िशन इनके लिए सेट होनी चाहिए:
digitalSignature
बिट की पोज़िशन इनके लिए सेट की जा सकती हैं:
nonRepudiation/contentCommitment
keyAgreement
encipherOnly (if keyAgreement is set)
decipherOnly (if keyAgreement is set)

अन्य बिट पोज़िशन सेट नहीं होनी चाहिए.
एक्सटेंडेड की यूसेज ज़रूरी है कोई एक

ये मौजूद होने चाहिए:
emailProtection
ये मौजूद नहीं होने चाहिए:
serverAuth
codeSigning
timeStamping
anyExtendedKeyUsage

बुनियादी पाबंदियां

 वैकल्पिक कोई एक

अगर यह मौजूद है, तो cA फ़ील्ड को true पर सेट नहीं किया जाना चाहिए
pathLenConstraint फ़ील्ड मौजूद नहीं होना चाहिए
सर्टिफ़िकेट की नीतियां ज़रूरी है नहीं

यह जानकारी मौजूद होनी चाहिए: एक policyIdentifier दिया जाना चाहिए, जिससे यह पता चले कि सर्टिफ़िकेट किस नीति के तहत जारी किया गया था. साथ ही, यह anyPolicy नहीं होना चाहिए.

मौजूद हो सकता है: cps. अगर यह मौजूद है, तो इसमें उस सीपीएस का मान्य एचटीटीपी या एचटीटीपीएस लिंक होना चाहिए जिसके तहत सर्टिफ़िकेट जारी किया गया था.

अथॉरिटी इनफ़ॉर्मेशन ऐक्सेस

 वैकल्पिक नहीं

caIssuers और अगर मौजूद है, तो ocsp में कम से कम एक ऐसा एचटीटीपी यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर होना चाहिए जिसे कोई भी ऐक्सेस कर सके.

AccessDescription में ऐसे लेबल या पैरामीटर नहीं होने चाहिए जो किसी एक सर्टिफ़िकेट के लिए खास हों.
सीआरएल डिस्ट्रिब्यूशन पॉइंट ज़रूरी है नहीं

कम से कम एक ऐसा
HTTPuniformResourceIdentifier मौजूद होना चाहिए जिसे सार्वजनिक तौर पर ऐक्सेस किया जा सके

(ध्यान दें)

रद्द करने वाले सर्वर को, CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates के वर्शन 1.3.2 या इससे ज़्यादा के इन सेक्शन के मुताबिक काम करना होगा:

  • 4.9.7. सीआरएल जारी करने की फ़्रीक्वेंसी
  • 4.9.9. सर्टिफ़िकेट निरस्त करने/स्थिति की जांच करने की ऑनलाइन सुविधा की उपलब्धता
  • 4.9.10. ऑनलाइन निरस्तीकरण की जांच करने की ज़रूरी शर्तें
  • 4.10.2. सेवा की उपलब्धता

विषय का वैकल्पिक नाम

 ज़रूरी है नहीं

इसमें rfc822Name टाइप का कम से कम एक आइटम होना चाहिए.
इसमें इस तरह के आइटम नहीं होने चाहिए:
dNSName
iPAddress
uniformResourceIdentifier
हर rfc822Name की पुष्टि, सार्वजनिक तौर पर उपलब्ध दस्तावेज़ और ऑडिट किए गए तरीकों से की जानी चाहिए. इससे यह पक्का किया जा सकेगा कि अनुरोध सबमिट करने वाली इकाई, ईमेल पते से जुड़े ईमेल खाते को कंट्रोल करती है या ईमेल खाते के मालिक ने उसे खाते के मालिक की ओर से कार्रवाई करने की अनुमति दी है.

कोई अन्य एक्सटेंशन

 वैकल्पिक नहीं यह मौजूद हो सकता है.