‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פרופילים של אישורי S/MIME

במאמר הזה מפורטים התנאים שכל אישור בשרשרת X.509 צריך לעמוד בהם כדי שיוגדר כמהימן לשימוש באימייל מוצפן או באימייל שנחתם באמצעות S/MIME.

בנוסף לדרישות האלה, השרשרת צריכה להיות מעוגנת לאישור של רשות אישורים (CA) ש-Google סומכת עליה באופן מפורש למטרה הזו. אפשר גם לבחור לקבל אישורי בסיס מרשויות אישורים שאתם סומכים עליהן. למידע נוסף, אפשר לעיין בהנחיות לגבי אישור בסיס.

הערות:

‫Google מספקת רשימה של אישורי CA שמוגדרים כמהימנים ב-Gmail לשימוש ב-S/MIME, וגם מתחזקת אותה. רשימת הרשויות להנפקת אישורים (CA) מהימנה אך ורק על פי שיקול דעתה של Google. ‫Google שומרת לעצמה את הזכות להסיר רשויות אישורים בסיסיות בכל שלב ללא הודעה מוקדמת.
מוודאים שהתוספים המותקנים לא סותרים תוספים אחרים באותו אישור. לדוגמה, אם מוגדרים nsCertTypes, הם צריכים לכסות את אותם שימושים בדיוק כמו התוסף key usage, התוסף extended key usage והתוסף basic constraints.

כללים של שרשרת אישורים

רשות אישורים (CA) עליונה

שדה	ערך
שם דומיין של המנפיק	צריך לזהות את רשות האישורים. לדוגמה, ה-DN לא יכול להיות ערך כללי כמו 'רשות אישורים'.
שם דומיין של הנושא	הטופס המקודד חייב להיות זהה בבייט ל-DN של המנפיק.
פרטי מפתח ציבורי של נושא	‫rsaEncryption עם מודול RSA של 2048,‏ 3072 או 4096. או ecPublicKey באמצעות secp256r1 או secp384r1.

שדה

ערך

שם דומיין של המנפיק

צריך לזהות את רשות האישורים.

לדוגמה, ה-DN לא יכול להיות ערך כללי כמו 'רשות אישורים'.

שם דומיין של הנושא

הטופס המקודד חייב להיות זהה בבייט ל-DN של המנפיק.

פרטי מפתח ציבורי של נושא

‫rsaEncryption עם מודול RSA של 2048,‏ 3072 או 4096. או ecPublicKey באמצעות secp256r1 או secp384r1.

אישורי ביניים של CA שאינם מה-CA המנפיק

משתמשים במידע הזה אם יש יותר מ-CA ביניים אחד בין שורש לבין ישות קצה, באופן ישיר או עקיף.

רשות האישורים ברמת הביניים שמנפיקה את האישור היא רשות האישורים ברמת הביניים שמנפיקה את האישור של ישות הקצה. הסעיף הזה רלוונטי לכל רשויות אישורים ברמת הביניים בשרשרת, מלבד רשות האישורים ברמת הביניים שהנפיקה את האישור.

שדה			ערך
גרסה			גרסה 3
מספר סידורי			הערך חייב להיות גדול מאפס (0). כשמבצעים קידוד DER כמספר שלם, הערך חייב להיות קטן מ-20 בייטים או שווה ל-20 בייטים.
אלגוריתם חתימה			‫RSA עם SHA‐256,‏ SHA‐384 או SHA‐512. או ECDSA עם SHA‐256,‏ SHA‐384 או SHA‐512
שם דומיין של המנפיק			הערך חייב להיות זהה לחלוטין לערך של Subject DN של רשות האישורים המנפיקה.
תקופת תוקף			אין תנאי
שם דומיין של הנושא			אין תנאי
פרטי מפתח ציבורי של נושא			‫rsaEncryption עם מודול RSA של 2048,‏ 3072 או 4096. או ecPublicKey באמצעות secp256r1 או secp384r1
תוסף	נוכחות	קריטי	ערך
שימוש במפתח	חובה	כן	צריך להגדיר את מיקומי הביטים עבור: keyCertSign אפשר להגדיר מיקומי ביטים אחרים
מגבלות בסיסיות	חובה	כן	השדה cA צריך להיות מוגדר כ-true צריך לכלול את השדה pathLenConstraint
נקודות הפצה של CRL	חובה	לא	צריך לציין לפחות מזהה משאב אחיד (URI) אחד של HTTP שנגיש לכולם
(הערה)			שרתי ביטול צריכים לעמוד בדרישות הבאות של מדיניות האישורים של CA/Browser Forum Baseline Requirements בנושא הנפקה וניהול של אישורים מהימנים לציבור, גרסה 1.3.2 ואילך: ‫4.9.7. תדירות הנפקת CRL ‫4.9.9. זמינות של בדיקת ביטול או סטטוס אונליין ‫4.9.10. דרישות לבדיקת ביטול באינטרנט 4.10.2 זמינות השירות
תוספים אחרים			יכול להיות שקיים

אישור ביניים של רשות אישורים שמנפיקה את ישות הקצה

חשוב: בשרשרת צריך להיות לפחות אישור CA ביניים אחד. חובה. כלומר, רשות הבסיס לא יכולה להנפיק ישירות אישורים של ישויות קצה.

שדה			ערך
גרסה			גרסה 3
מספר סידורי			הערך חייב להיות גדול מאפס (0), וכשהוא מקודד ב-DER כמספר שלם, הוא צריך להיות קטן מ-20 בייט או שווה ל-20 בייט.
אלגוריתם חתימה			‫RSA עם SHA‐256,‏ SHA‐384 או SHA‐512. או ECDSA עם SHA‐256,‏ SHA‐384 או SHA‐512.
שם דומיין של המנפיק			הערך חייב להיות זהה לחלוטין לערך של Subject DN של רשות האישורים המנפיקה.
תקופת תוקף			ההבדל בין notBefore לבין notAfter התקופה לא יכולה להיות ארוכה מ-10 שנים, ולא יכולה להיות ארוכה מ-20 שנים.
שם דומיין של הנושא			צריך לציין את השימוש ב-CA.
פרטי מפתח ציבורי של נושא			‫rsaEncryption עם מודול RSA של 2048,‏ 3072 או 4096. או ecPublicKey באמצעות secp256r1 או secp384r1
תוסף	נוכחות	קריטי	ערך
שימוש במפתח	חובה	כן	צריך להגדיר את מיקומי הביטים עבור: keyCertSign אפשר להגדיר את מיקומי הביטים עבור: cRLSign digitalSignature אם נעשה שימוש ישיר בחתימה על תגובות OCSP, צריך להגדיר את: digitalSignature אסור להגדיר מיקומי ביטים אחרים
שימוש מורחב במפתח	חובה	אחד מהם	חייב להיות נוכח: emailProtection אסור להיות נוכח: serverAuth codeSigning timeStamping anyExtendedKeyUsage
מגבלות בסיסיות	חובה	כן	השדה cA חייב להיות מוגדר כ-true השדה pathLenConstraint צריך להיות נוכח ומוגדר כ-0
מדיניות אישורים	אופציונלי	לא	צריך לספק policyIdentifier שמזהה את המדיניות שלפיה פועלת רשות האישורים, והוא לא יכול להיות anyPolicy. אם יש cps, הוא חייב להכיל קישור תקין מסוג HTTP או HTTPS.
נקודות הפצה של CRL	חובה	לא	צריך לציין לפחות מזהה משאב אחיד (URI) אחד של HTTP שנגיש לכולם.
(הערה)			שרתי ביטול צריכים לפעול בהתאם לסעיפים הבאים של מדיניות האישורים של CA/Browser Forum Baseline Requirements בנושא הנפקה וניהול של אישורים מהימנים לציבור, גרסה 1.3.2 ואילך: ‫4.9.7. תדירות הנפקת CRL ‫4.9.9. זמינות של בדיקת ביטול או סטטוס אונליין ‫4.9.10. דרישות לבדיקת ביטול אונליין ‫4.10.2. זמינות השירות
תוספים אחרים	אופציונלי	לא	יכול להיות שיופיע.

אישור של ישות קצה

שדה			ערך
גרסה			גרסה 3
מספר סידורי			הערך חייב להיות גדול מאפס (0) והוא צריך להכיל לפחות 64 ביטים בלתי צפויים. הערה: המאמר הזה יעודכן בהתאם לדרישות האנטרופיה של המספר הסידורי של ישות הקצה שמופיעות במדיניות האישורים של CA/Browser Forum Baseline Requirements.
אלגוריתם חתימה			‫RSA עם SHA‐256,‏ SHA‐384 או SHA‐512. או ECDSA עם SHA‐256,‏ SHA‐384 או SHA‐512.
שם דומיין של המנפיק			הערך חייב להיות זהה לחלוטין לערך של Subject DN של רשות האישורים המנפיקה.
תקופת תוקף			ההפרש בין התאריכים notBefore ו-notAfter לא יכול להיות ארוך מ-27 חודשים. השעה שנקבעה ב-notBefore צריכה להיות השעה של החתימה פלוס או מינוס 48 שעות.
שם דומיין של הנושא			כל שמות יחסיים מובחנים של נושאים, מלבד כתובת אימייל, חייבים לעבור תהליך אימות קפדני לפני הנפקתם, באמצעות הליך שמתועד ונבדק באופן ציבורי. הליך מקובל מפורט בקטע 3.2.3 'אימות של זהות אישית' במדיניות האישורים של CA/Browser Forum Baseline Requirements בנושא הנפקה וניהול של אישורים מהימנים לציבור, גרסה 1.3.2 ואילך. כל כתובות האימייל (לדוגמה, בשדות commonName או emailAddress) צריכות להופיע גם בתוסף Subject Alternate Name בתור rfc822Name.
פרטי מפתח ציבורי של נושא			‫rsaEncryption עם מודול RSA של 2048,‏ 3072 או 4096. או ecPublicKey באמצעות secp256r1 או secp384r1
תוסף	נוכחות	קריטי	ערך
שימוש במפתח (RSA)	חובה	כן	צריך להגדיר את מיקומי הביטים עבור: digitalSignature ו/או nonRepudiation/contentCommitment אפשר להגדיר את מיקומי הביטים עבור: dataEncipherment keyEncipherment אסור להגדיר מיקומי ביטים אחרים.
שימוש במפתח (ECDH)	חובה		חובה להגדיר את מיקומי הביטים עבור: digitalSignature אפשר להגדיר את מיקומי הביטים עבור: nonRepudiation/contentCommitment keyAgreement encipherOnly (אם מוגדר keyAgreement) decipherOnly (אם מוגדר keyAgreement) אסור להגדיר מיקומי ביטים אחרים.
שימוש מורחב במפתח	חובה	אחד מהם	חייב להיות נוכח: emailProtection אסור להיות נוכח: serverAuth codeSigning timeStamping anyExtendedKeyUsage
מגבלות בסיסיות	אופציונלי	אחד מהם	אם השדה הזה קיים, השדה cA לא יכול להיות מוגדר כ-true השדה pathLenConstraint לא יכול להיות קיים
מדיניות אישורים	חובה	לא	חובה: צריך לספק policyIdentifier שמזהה את המדיניות שלפיה הונפק האישור, ואסור שיהיה anyPolicy. יכול להיות שיופיע: cps. אם הוא מופיע, הוא חייב להכיל קישור תקין מסוג HTTP או HTTPS ל-CPS שבו הונפק האישור.
גישה לפרטי רשות	אופציונלי	לא	השדות caIssuers ו-ocsp, אם הם קיימים, חייבים להכיל לפחות מזהה משאב אחיד (URI) של HTTP שנגיש לציבור. השדה AccessDescription לא יכול להכיל תוויות או פרמטרים שספציפיים לאישור מסוים.
נקודות הפצה של CRL	חובה	לא	צריך לציין לפחות מזהה משאב אחיד (URI) ל-HTTP שזמין לגישה ציבורית
(הערה)			שרתי ביטול צריכים לפעול בהתאם לסעיפים הבאים של מדיניות האישורים של CA/Browser Forum Baseline Requirements בנושא הנפקה וניהול של אישורים מהימנים לציבור, גרסה 1.3.2 ואילך: ‫4.9.7. תדירות הנפקת CRL ‫4.9.9. זמינות של בדיקת ביטול או סטטוס אונליין ‫4.9.10. דרישות לבדיקת ביטול אונליין ‫4.10.2. זמינות השירות
שם חלופי של בעלים (subject)	חובה	לא	חייב להכיל לפחות פריט אחד מהסוג rfc822Name. לא יכול להכיל פריטים מהסוגים: dNSName iPAddress uniformResourceIdentifier כל rfc822Name צריך להיות מאומת באמצעות אמצעים שמתועדים ומבוקרים באופן ציבורי, כדי לוודא שהגורם ששולח את הבקשה שולט בחשבון האימייל שמשויך לכתובת האימייל, או שבעל חשבון האימייל אישר לו לפעול בשמו.
תוספים אחרים	אופציונלי	לא	יכול להיות שיופיע.

פרופילים של אישורי S/MIME קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.