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

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

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

הערות:

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

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

רשות אישורים בסיסית

שדה ערך

‫DN של המוסד המנפיק

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

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

ה-DN של הנושא

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

מידע על המפתח הציבורי של הנושא

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

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

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

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

שדה ערך
גרסה גרסה 3
מספר סידורי הערך חייב להיות גדול מאפס (0). כשמבצעים קידוד DER כמספר שלם, הערך חייב להיות קטן מ-20 בייט או שווה לו.
אלגוריתם חתימה ‫RSA עם SHA‐256,‏ SHA‐384 או SHA‐512. או ECDSA עם SHA‐256,‏ SHA‐384 או SHA‐512
‫DN של המוסד המנפיק

הערך צריך להיות זהה לחלוטין לערך של שם הנושא (DN) של רשות האישורים המנפיקה.
תוקף אין תנאי
ה-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 ביניים שמנפיק את ישות הקצה

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

שדה ערך
גרסה גרסה 3
מספר סידורי הערך חייב להיות גדול מאפס (0), וכשהוא מקודד ב-DER בתור INTEGER, הוא חייב להיות קטן מ-20 בייטים או שווה ל-20 בייטים.
אלגוריתם חתימה

‫RSA עם SHA‐256,‏ SHA‐384 או SHA‐512. או ECDSA עם SHA‐256,‏ SHA‐384 או SHA‐512.
‫DN של המוסד המנפיק

הערך צריך להיות זהה לחלוטין לערך של שם הנושא (DN) של רשות האישורים המנפיקה.
תוקף

ההבדל בין notBefore לבין notAfter

התקופה לא יכולה להיות ארוכה מ-10 שנים, ולא יכולה להיות ארוכה מ-20 שנים.
ה-DN של הנושא

צריך לציין את השימוש ברשות האישורים.
מידע על המפתח הציבורי של הנושא

‫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.
‫DN של המוסד המנפיק

הערך צריך להיות זהה לחלוטין לערך של שם הנושא (DN) של רשות האישורים המנפיקה.
תוקף

ההפרש בין התאריכים notBefore ו-notAfter לא יכול להיות ארוך מ-27 חודשים.

השעה של התכונה notBefore צריכה לייצג את השעה של החתימה בתוספת או בהפחתה של 48 שעות.
ה-DN של הנושא

כל שמות יחסיים מובחנים של נושאים, מלבד כתובת אימייל, צריכים לעבור תהליך אימות קפדני לפני הנפקתם, באמצעות הליך שמתועד ומבוקר באופן פומבי. הליך מקובל מפורט בקטע 3.2.3 'אימות של זהות אישית' במדיניות האישורים של CA/Browser Forum בנושא דרישות בסיסיות להנפקה ולניהול של אישורים מהימנים לציבור, גרסה 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 צריך להיות מאומת באמצעות אמצעים שמתועדים בגלוי ועוברים ביקורת, כדי לוודא שהגורם ששולח את הבקשה שולט בחשבון האימייל שמשויך לכתובת האימייל, או שבעל חשבון האימייל אישר לו לפעול בשמו.

כל תוסף אחר

 אופציונלי לא יכול להיות שיופיעו.