תאימות ל-RFC

Certificate Authority Service משתמש בכלי ZLint כדי לוודא שאישורי X.509 תקפים בהתאם לכללים של RFC 5280. עם זאת, CA Service לא אוכף את כל הדרישות של RFC 5280, ויכול להיות שרשות אישורים שנוצרה באמצעות CA Service תנפיק אישור שלא עומד בדרישות.

שירות ה-CA אוכף את הדרישות הבאות של RFC 5280.

סעיף RFC 5280 סעיף Lint
4.1.1.2 האלגוריתם signatureAlgorithm באישור חייב להכיל את אותו מזהה אלגוריתם כמו בשדה signature ברצף tbsCertificate (סעיף 4.1.2.3).
4.1.2.1 כשמשתמשים בתוספים, כמו שצפוי בפרופיל הזה, הערך של version חייב להיות 3 (הערך הוא 2).
4.1.2.2 המספר הסידורי חייב להיות מספר שלם חיובי שהוקצה על ידי רשות האישורים לכל אישור.
4.1.2.2 רשויות אישורים תואמות לא יכולות להשתמש בערכים של serialNumber באורך של יותר מ-20 אוקטטים.
4.1.2.4 השדה 'מנפיק' חייב להכיל שם ייחודי (DN) לא ריק.
4.1.2.5 רשויות אישורים שעומדות בדרישות הפרופיל הזה חייבות תמיד לקודד את תאריכי התוקף של האישורים עד שנת 2049 כ-UTCTime
4.1.2.5 כדי לציין שלאישור אין תאריך תפוגה מוגדר היטב, צריך להקצות ל-notAfter את הערך GeneralizedTime‏ 99991231235959Z.
4.1.2.5.1 ערכי UTCTime חייבים להיות מבוטאים לפי שעון גריניץ' (זולו)
4.1.2.5.1 ערכי UTCTime חייבים לכלול שניות
4.1.2.5.2 ערכי GeneralizedTime חייבים להיות מבוטאים לפי שעון גריניץ' (זולו)
4.1.2.5.2 השדה GeneralizedTime חייב לכלול שניות
4.1.2.5.2 הערכים של GeneralizedTime לא יכולים לכלול שניות חלקיות
4.1.2.6 אם הנושא הוא CA (לדוגמה, אם התוסף basic constraints, כפי שמתואר בקטע 4.2.1.9, קיים והערך של cA הוא TRUE), אז השדה subject חייב להיות מאוכלס בשם ייחודי לא ריק שתואם לתוכן של השדה issuer (קטע 4.1.2.4) בכל האישורים שהונפקו על ידי ה-CA של הנושא.
4.1.2.8 שדות של מזהים ייחודיים חייבים להופיע רק אם הגרסה היא 2 או 3
4.1.2.8 רשויות אישורים שעומדות בדרישות הפרופיל הזה לא יכולות ליצור אישורים עם מזהים ייחודיים.
4.1.2.9 השדה extensions חייב להופיע רק אם הגרסה היא 3
‫4.2 אישור לא יכול לכלול יותר ממופע אחד של תוסף מסוים.
‫4.2 אם רשות האישורים מנפיקה אישורים עם רצף ריק בשדה הבעלים (subject), רשות האישורים חייבת לתמוך בתוסף של שם חלופי של בעלים (subject)
4.2.1.1 שדה keyIdentifier של התוסף authorityKeyIdentifier חייב להיכלל בכל האישורים שנוצרו על ידי רשויות אישורים תואמות, כדי לאפשר בנייה של נתיב אישורים.
4.2.1.1 רשויות אישורים תואמות חייבות לסמן את התוסף authorityKeyIdentifier כלא קריטי.
4.2.1.2 כדי לאפשר בנייה של נתיב אישורים, הרכיב authorityKeyIdentifier חייב להופיע בכל אישורי ה-CA התואמים, כלומר בכל האישורים כולל התוסף basic constraints (סעיף 4.2.1.9) שבו הערך של cA הוא TRUE.
4.2.1.2 רשויות אישורים תואמות חייבות לסמן את תוסף מזהה מפתח הנושא כלא קריטי.
4.2.1.2 כדי לעזור לאפליקציות לזהות את אישור ישות הקצה המתאים, התוסף הזה צריך להיכלל בכל אישורי ישות הקצה
4.2.1.3 אם הביט keyCertSign מוגדר כ-true, גם הביט cA בתוסף basic constraints (סעיף 4.2.1.9) חייב להיות מוגדר כ-true.
4.2.1.3 כשתוסף keyUsage מופיע באישור, לפחות אחד מהביטים חייב להיות מוגדר כ-1.
4.2.1.3 אם התוסף הזה קיים, רשויות אישורים תואמות צריכות לסמן אותו כתוסף קריטי.
4.2.1.4 מזהה אובייקט (OID) של מדיניות אישורים לא יכול להופיע יותר מפעם אחת בתוסף של מדיניות אישורים.
4.2.1.4 כשמשתמשים במגבילים עם המדיניות המיוחדת anyPolicy, חובה להגביל אותם למגבילים שמפורטים בקטע הזה.
4.2.1.4 רשויות אישורים שעומדות בדרישות לא צריכות להשתמש באפשרות noticeRef.
4.2.1.4 רשויות אישורים תואמות צריכות להשתמש בקידוד UTF8String בשדה explicitText, אבל יכולות להשתמש גם ב-IA5String.
4.2.1.4 המחרוזת explicitText לא אמורה לכלול תווי בקרה (למשל, U+0000 עד U+001F ו-U+007F עד U+009F).
4.2.1.4 כשמשתמשים בקידוד UTF8String, כל רצפי התווים צריכים להיות מנורמלים בהתאם לטופס הנורמליזציה C ‏ (NFC) של Unicode
4.2.1.5 אסור למפות מדיניות לערך המיוחד anyPolicy או ממנו
4.2.1.5 כל issuerDomainPolicy שמוזכר בתוסף מיפוי המדיניות צריך להיות מוצהר גם בתוסף מדיניות האישורים באותו אישור.
4.2.1.5 רשויות אישורים תואמות צריכות לסמן את התוסף הזה של מיפוי מדיניות כקריטי.
4.2.1.6 בכל פעם שרוצים לקשור זהויות כאלה (כל דבר ב-SAN) לאישור, חובה להשתמש בתוסף Subject Alternative Name (או Issuer Alternative Name).
4.2.1.6 אם שדה הנושא מכיל רצף ריק, רשות האישורים המנפיקה חייבת לכלול תוסף subjectAltName שמסומן כקריטי.
4.2.1.6 כשהתוסף subjectAltName מכיל כתובת אימייל באינטרנט, הכתובת חייבת להיות מאוחסנת ב-rfc822Name.
4.2.1.6 בגרסה 4 של כתובת IP, כפי שמצוין ב-‎[RFC 791], מחרוזת האוקטטים חייבת להכיל בדיוק ארבעה אוקטטים. בגרסה 6 של כתובת IP, כפי שמצוין ב-‎[RFC 2460], מחרוזת האוקטטים חייבת להכיל בדיוק 16 אוקטטים.
4.2.1.6 כשהתוסף subjectAltName מכיל תווית של מערכת שמות דומיין, שם הדומיין חייב להיות מאוחסן ב-dNSName (מחרוזת IA5).
4.2.1.6 שמות חלופיים: הערך dNSName חייב להיות בפורמט של "תחביר השם המועדף"
4.2.1.6 אסור להשתמש בתוספי subjectAltName עם dNSName של " "
4.2.1.6 אסור להשתמש בייצוג DNS של כתובות אימייל באינטרנט (subscriber.example.com במקום subscriber@example.com)
4.2.1.6 כשהתוסף subjectAltName מכיל URI, השם חייב להיות מאוחסן ב-uniformResourceIdentifier (מחרוזת IA5).
4.2.1.6 כתובות URI של SAN: השם לא יכול להיות כתובת URI יחסית, והוא חייב להיות בהתאם לתחביר ולכללי הקידוד של כתובות URI שמפורטים ב-RFC 3986.
4.2.1.6 כתובות URI של SAN: השם חייב לכלול גם סכימה (למשל, 'http' או 'ftp') וגם חלק ספציפי לסכימה.
4.2.1.6 כתובות URI של SAN שכוללות רשות ([RFC 3986], סעיף 3.2) חייבות לכלול שם דומיין שמוגדר במלואו או כתובת IP כמארח.
4.2.1.6 אם התוסף subjectAltName קיים, הרצף חייב להכיל לפחות רשומה אחת.
4.2.1.6 רשויות אישורים (CA) תואמות לא יכולות להנפיק אישורים עם subjectAltNames שמכילים שדות GeneralName ריקים.
4.2.1.6 כשכוללים את התוסף subjectAltName באישור שיש לו שם נושא מובחן לא ריק, רשויות אישורים תואמות צריכות לסמן את התוסף subjectAltName כלא קריטי.
4.2.1.7 השם החלופי של המנפיק חייב להיות מקודד כמו בסעיף 4.2.1.6
4.2.1.7 אם התוסף הזה קיים, רשויות אישורים תואמות צריכות לסמן את התוסף הזה של שם חלופי של מנפיק כלא קריטי.
4.2.1.8 מאפיינים של ספריית הנושא: רשויות אישורים תואמות חייבות לסמן את התוסף הזה כלא קריטי.
4.2.1.9 במקום שבו הוא מופיע, השדה pathLenConstraint חייב להיות גדול מאפס או שווה לו.
4.2.1.9 רשויות אישורים תואמות חייבות לכלול את התוסף הזה בכל אישורי רשות האישורים שמכילים מפתחות ציבוריים שמשמשים לאימות חתימות דיגיטליות באישורים, וחייבות לסמן את התוסף כקריטי באישורים כאלה.
4.2.1.9 רשויות אישורים (CA) לא יכולות לכלול את השדה pathLenConstraint אלא אם הערך הבוליאני cA הוא true והביט keyCertSign מוגדר בתוסף key usage.
4.2.1.10 תוסף מגבלות השם, שחובה להשתמש בו רק באישור CA, מציין מרחב שמות שבו חייבים להיות כל שמות הנושאים באישורים הבאים בנתיב האישורים.
4.2.1.10 מגבלות שם: רשויות אישורים תואמות חייבות לסמן את התוסף הזה כקריטי
4.2.1.10 רשויות אישורים תואמות לא יכולות להנפיק אישורים שבהם אילוצי השם הם רצף ריק. כלומר, השדה permittedSubtrees או השדה excludedSubtrees חייבים להיות נוכחים.
4.2.1.10 בפרופיל הזה, השדות של המינימום והמקסימום לא משמשים עם שום צורה של שם, ולכן המינימום חייב להיות אפס והמקסימום חייב להיות ריק.
4.2.1.10 התחביר של iPAddress חייב להיות כפי שמתואר בקטע 4.2.1.6 עם התוספות הבאות שספציפיות לאילוצי שם: עבור כתובות IPv4, השדה iPAddress של GeneralName חייב להכיל שמונה (8) אוקטטים, שמוצפנים בסגנון של RFC 4632 ‏ (CIDR) כדי לייצג טווח כתובות [RFC 4632]. בכתובות IPv6, השדה iPAddress חייב להכיל 32 אוקטטים שמקודדים באופן דומה.
4.2.1.10 לא צריכות להיות הגבלות על שמות בפורמטים x400Address,‏ ediPartyName או registeredID.
4.2.1.11 רשויות אישורים תואמות לא יכולות להנפיק אישורים שבהם אילוצי המדיניות הם רצף ריק. כלומר, השדה inhibitPolicyMapping או השדה requireExplicitPolicy חייבים להופיע.
4.2.1.11 אילוצים של מדיניות: רשויות אישורים תואמות חייבות לסמן את התוסף הזה כקריטי.
4.2.1.12 אם קיים KeyPurposeId כלשהו של anyExtendedKeyUsage, רשויות אישורים תואמות לא צריכות לסמן את התוסף הזה כקריטי.
4.2.1.13 המאפיין DistributionPoint לא יכול לכלול רק את השדה reasons. צריך לציין גם את distributionPoint או את cRLIssuer.
4.2.1.13 התוסף CRL Distribution Points (נקודות הפצה של CRL) צריך להיות לא קריטי
4.2.1.13 אם יש DistributionPointName, הוא צריך לכלול לפחות URI אחד של LDAP או HTTP.
4.2.1.13 רשויות אישורים תואמות לא צריכות להשתמש ב-nameRelativeToCRLIssuer כדי לציין שמות של נקודות הפצה.
4.2.1.14 רשויות אישורים תואמות חייבות לסמן את התוסף הזה Inhibit anyPolicy כקריטי.
4.2.1.15 רשויות אישורים תואמות חייבות לסמן את התוסף Freshest CRL כלא קריטי.
4.2.2.1 רשויות אישורים שעומדות בדרישות חייבות לסמן את התוסף הזה של גישה למידע על הרשות כלא קריטי.
4.2.2.1 כשמשתמשים ב-accessMethod‏ id-ad-caIssuers, לפחות מופע אחד צריך לציין accessLocation שהוא HTTP [RFC 2616] או LDAP [RFC 4516] URI.
4.2.2.2 רשויות אישורים תואמות חייבות לסמן את התוסף הזה של גישה למידע על הנושא כלא קריטי.
‫7.2 כדי להתאים את המבנה הנוכחי לשמות דומיין בינלאומיים, יישומי תאימות חייבים להמיר שמות דומיין בינלאומיים לפורמט ASCII Compatible Encoding ‏ (ACE) כפי שמפורט בקטע 4 של RFC 3490 לפני האחסון בשדה dNSName.