All Classes and Interfaces
Class
Description
This lint refers to CAB Baseline
Requirements (Version 1.7.4) chapter 7.1.3.1, which defines the
required encodings of AlgorithmObjectIdentifiers inside a SubjectPublicKeyInfo field.
RFC 5280: 4.2.1.9
Conforming CAs MUST include this extension in all CA certificates that contain
public keys used to validate digital signatures on certificates and MUST mark
the extension as critical in such certificates.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.1
If the Certificate complies with these requirements and lacks Subject identity information that
has been verified in accordance with Section 3.2.2.1 or Section 3.2.3.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.1
If the Certificate complies with these requirements and lacks Subject identity information that
has been verified in accordance with Section 3.2.2.1 or Section 3.2.3.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.1
If the Certificate complies with these requirements and lacks Subject identity information that
has been verified in accordance with Section 3.2.2.1 or Section 3.2.3.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.1
If the Certificate complies with these requirements and lacks Subject identity information that
has been verified in accordance with Section 3.2.2.1 or Section 3.2.3.
7.1.2.7.2 Domain Validated
The following table details the acceptable AttributeTypes that may appear within the type
field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.3
If the Certificate complies with these Requirements and includes Subject Identity Information
that is verified in accordance with Section 3.2.3.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.2
If the Certificate complies with these Requirements and includes Subject Identity Information
that is verified in accordance with Section 3.2.2.1.
BRs: 7.1.2.1e
The Certificate Subject MUST contain the following:
- countryName (OID 2.5.4.6).
BRs: 7.1.2.1e
The Certificate Subject MUST contain the following:
- countryName (OID 2.5.4.6).
BRs: 7.1.2.1b
This extension MUST be present and MUST be marked critical.
BRs: 7.1.2.1b: Root CA Certificate keyUsage
This extension MUST be present and MUST be marked critical.
BRs: 7.1.2.1b
This extension MUST be present and MUST be marked critical.
RFC 5280: 4.2.1.3
Conforming CAs MUST include this extension in certificates that
contain public keys that are used to validate digital signatures on
other public key certificates or CRLs.
BRs: 7.1.2.1b
This extension MUST be present and MUST be marked critical.
BRs: 7.1.2.1e
The Certificate Subject MUST contain the following: organizationName (OID 2.5.4.10): This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2.
RFC 5280: 4.1.2.6
The subject field identifies the entity associated with the public
key stored in the subject public key field.
These fields MUST only appear if the version is 2 or 3 (Section 4.1.2.1).
4.1.2.1.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.3
If the Certificate complies with these Requirements and includes Subject Identity Information
that is verified in accordance with Section 3.2.3.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.3
If the Certificate complies with these Requirements and includes Subject Identity Information
that is verified in accordance with Section 3.2.3.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.2
If the Certificate complies with these Requirements and includes Subject Identity Information
that is verified in accordance with Section 3.2.2.1.
BRs: 7.1.6.4
Certificate Policy Identifier: 2.23.140.1.2.2
If the Certificate complies with these Requirements and includes Subject Identity Information
that is verified in accordance with Section 3.2.2.1.
RFC 5280: 4.1.1.2
[the Certificate signatureAlgorithm] field MUST contain the same
algorithm identifier as the signature field in the sequence
tbsCertificate
RFC 5280: 4.1.2.8
These fields MUST only appear if the version is 2 or 3 (Section 4.1.2.1).
RFC 5280: 5.1.2.5
Conforming CRL issuers MUST include the nextUpdate field in all CRLs.
The cRLDistributionPoints extension is a SEQUENCE of
DistributionPoint.
RFC 5280: 4.2.1.13
When present, DistributionPointName SHOULD include at least one LDAP or HTTP URI.
RFC 8813: 3.
BRs: 6.1.5
Certificates MUST meet the following requirements for algorithm type and key size.
RFC 5280: 4.2.1.12
If a CA includes extended key usages to satisfy such applications,
but does not wish to restrict usages of the key, the CA can include
the special KeyPurposeId anyExtendedKeyUsage in addition to the
particular key purposes required by the applications.
RFC 5280: 4.2.2.1
An authorityInfoAccess extension may include multiple instances of
the id-ad-caIssuers accessMethod.
Authority Information Access
The authority information access extension indicates how to access
information and services for the issuer of the certificate in which
the extension appears.
RFC 5280: 4.2.1.1
Conforming CAs MUST mark this extension as non-critical.
RFC 5280: 4.2.1.1
The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction.
The user notice has two optional fields: the noticeRef field and the
explicitText field.
RFC 5280: 4.2.1.4
To promote interoperability, this profile RECOMMENDS that policy
information terms consist of only an OID.
The certificate policies extension contains a sequence of one or more
policy information terms, each of which consists of an object identifier
(OID) and optional qualifiers.
An explicitText field includes the textual statement directly in
the certificate.
An explicitText field includes the textual statement directly in
the certificate.
When the UTF8String encoding is used, all character sequences SHOULD be
normalized according to Unicode normalization form C (NFC) [NFC].
https://tools.ietf.org/html/rfc6818#section-3
An explicitText field includes the textual statement directly in
the certificate.
An explicitText field includes the textual statement directly in
the certificate.
The CRL distribution points extension identifies
how CRL information is obtained.
"A certificate MUST NOT include more than one
instance of a particular extension."
The freshest CRL extension identifies how delta CRL
information is obtained.
Issuer Alternative Name
As with Section 4.2.1.6, this extension is used to
associate Internet style identities with the certificate
issuer.
RFC 5280: 4.2.1.7
When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the DNSName (an IA5String).
RFC 5280: 4.2.1.7
If the subjectAltName extension is present, the sequence MUST contain
at least one entry.
RFC 5280: 4.2.1.7
If the issuerAltName extension is present, the sequence MUST contain
at least one entry.
RFC 5280: 4.2.1.6
When the issuerAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name.
RFC 5280: 4.2.1.7
When the issuerAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST include both a
scheme (e.g., "http" or "ftp") and a scheme-specific-part.
When the issuerAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String).
When the issuerAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String).
RFC 5280: 4.2.1.9
The cA boolean indicates whether the certified public key may be used
to verify certificate signatures.
This profile does not restrict the combinations of bits that may be
set in an instantiation of the keyUsage extension.
Restrictions are defined in terms of permitted or excluded name
subtrees.
RFC 5280: 4.2.1.10
The name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names in
subsequent certificates in a certification path MUST be located.
RFC 5280: 4.2.1.11
Conforming CAs MUST NOT issue certificates where policy constraints
is an empty sequence.
RFC 5280: 4.2.1.11
Conforming CAs MUST mark this extension as critical.
RFC 5280: 4.2.1.5
Each issuerDomainPolicy named in the policy mappings extension SHOULD
also be asserted in a certificate policies extension in the same
certificate.
RFC 5280: 4.2.1.5.
RFC 5280: 4.2.1.5
Each issuerDomainPolicy named in the policy mapping extension SHOULD
also be asserted in a certificate policies extension in the same
certificate.
Further, if the only subject identity included in the certificate is an
alternative name form (e.g., an electronic mail address), then the subject
distinguished name MUST be empty (an empty sequence), and the subjectAltName
extension MUST be present.
7.1.4.2.1.
RFC 5280: 4.2.1.6
When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
7.1.4.2.1.
RFC 5280: 4.2.1.6
If the subjectAltName extension is present, the sequence MUST contain
at least one entry.
BRs: 7.1.4.2.1
Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required
RFC 5280: 4.2.1.6
If the subjectAltName extension is present, the sequence MUST contain
at least one entry.
RFC 5280: 4.2.1.6
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present.
7.1.4.2.1.
7.1.4.2.1.
RFC 5280: 4.2.1.6
When the subjectAltName extension contains an Internet mail address,
the address MUST be stored in the rfc822Name.
7.1.4.2.1.
RFC 5280: 4.2.1.6
When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
7.1.4.2.1.
The name MUST include both a
scheme (e.g., "http" or "ftp") and a scheme-specific-part.
When the subjectAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String).
When the subjectAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String).
RFC 5280: 4.2.1.8
The subject directory attributes extension is used to convey
identification attributes (e.g., nationality) of the subject.
RFC 5280: 4.2.1.2
Conforming CAs MUST mark this extension as non-critical.
To facilitate certification path construction, this extension MUST
appear in all conforming CA certificates, that is, all certificates
including the basic constraints extension (Section 4.2.1.9) where the
value of cA is TRUE.
To facilitate certification path construction, this extension MUST
appear in all conforming CA certificates, that is, all certificates
including the basic constraints extension (Section 4.2.1.9) where the
value of cA is TRUE.
RFC5280 suggested the addition of SKI extension, but CABF BR SC62
marked the extension as NOT RECOMMENDED for subscriber certificates
Warning:
Users of zlint will trigger either
`w_ext_subject_key_identifier_not_recommended_subscriber` (this lint)
or `w_ext_subject_key_identifier_missing_sub_cert` the one enforcing
RFC5280's behavior.
4.1.2.5.2.
4.1.2.5.2.
4.2.1.14.
Certificates MUST be of type X.509 v3.
RFC 5280: 4.1.2.4
The issuer field identifies the entity that has signed and issued the
certificate.
Section 5.3 - Intermediate Certificates
Intermediate certificates created after January 1, 2019, with the exception
of cross-certificates that share a private key with a corresponding root
certificate: MUST contain an EKU extension; and, MUST NOT include the
anyExtendedKeyUsage KeyPurposeId; and, * MUST NOT include both the
id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same
certificate.
Section 5.2 - Forbidden and Required Practices
CAs MUST NOT issue certificates that have:
- incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs
that include both the key ID and the issuer’s issuer name and serial number);
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
When ECDSA keys are encoded in a SubjectPublicKeyInfo structure, the algorithm field MUST be one of the following, as
specified by RFC 5480, Section 2.1.1:
The encoded AlgorithmIdentifier for a P-256 key MUST match the following hex-encoded
bytes: > 301306072a8648ce3d020106082a8648ce3d030107.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
When a root or intermediate certificate's ECDSA key is used to produce a signature, only the following algorithms may
be used, and with the following encoding requirements:
If the signing key is P-256, the signature MUST use ECDSA with SHA-256.
Section 5.2 - Forbidden and Required Practices
CAs MUST NOT issue certificates that have:
- invalid public keys (e.g., RSA certificates with public exponent equal to 1);
Section 5.1 - Algorithms
RSA keys whose modulus size in bits is divisible by 8, and is at least 2048.
Section 5.1 - Algorithms
RSA keys whose modulus size in bits is divisible by 8, and is at least 2048.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Section 5.1.1 RSA
CAs MUST NOT use the id-RSASSA-PSS OID (1.2.840.113549.1.1.10) within a SubjectPublicKeyInfo to represent a RSA key.
Restrictions are defined in terms of permitted or excluded name
subtrees.
RFC 5280: 4.2.1.10
Within this profile, the minimum and maximum fields are not used with
any name forms, thus, the minimum MUST be zero, and maximum MUST be
absent.
RFC 5280: 4.2.1.10
Within this profile, the minimum and maximum fields are not used with
any name forms, thus, the minimum MUST be zero, and maximum MUST be
absent.
RFC 5280: 4.2.1.10
Restrictions are defined in terms of permitted or excluded name
subtrees.
RFC 5280: 4.2.1.10
Restrictions are defined in terms of permitted or excluded name
subtrees.
RFC 5280: 4.2.1.10
Restrictions are defined in terms of permitted or excluded name
subtrees.
RFC 5280: 4.2.1.9
CAs MUST NOT include the pathLenConstraint field unless the cA
boolean is asserted and the key usage extension asserts the
keyCertSign bit.
The pathLenConstraint field is meaningful only if the cA boolean is
asserted and the key usage extension, if present, asserts the
keyCertSign bit (Section 4.2.1.3).
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Subsection 5.1 Algorithms
Root certificates in our root program, and any certificate which chains up to them, MUST use only algorithms and key sizes from the following set:
- RSA keys whose modulus size in bits is divisible by 8, and is at least 2048
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Section 5.1.1 RSA
RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes.
7.1.2.1.
BRs: 7.1.2.1c certificatePolicies
This extension SHOULD NOT be present.
BRs: 7.1.2.1d extendedKeyUsage
This extension MUST NOT be present.
RFC 3279: 2.3.1 RSA Keys
If the keyUsage extension is present in a CA or CRL issuer
certificate which conveys an RSA public key, any combination of the
following values MAY be present:
digitalSignature;
nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.
RFC 3279: 2.3.1 RSA Keys
If the keyUsage extension is present in an end entity certificate
which conveys an RSA public key, any combination of the following
values MAY be present:
digitalSignature;
nonRepudiation;
keyEncipherment; and
dataEncipherment.
RFC 3279: 2.3.1 RSA Keys
If the keyUsage extension is present in a CA or CRL issuer
certificate which conveys an RSA public key, any combination of the
following values MAY be present:
digitalSignature;
nonRepudiation;
keyEncipherment;
dataEncipherment;
keyCertSign; and
cRLSign.
6.1.6.
"BRs: 6.1.6"
RSA: The CA SHALL confirm that the value of the public
exponent is an odd number equal to 3 or more.
"BRs: 6.1.6"
RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more.
"BRs: 6.1.6"
RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more.
"BRs: 6.1.6"
RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more.
RFC 5280: 4.1.2.2.
4.1.2.2.
7.1.4.2.1 Subject alternative name extension
All Mailbox Addresses in the subject field or entries of type dirName of this extension SHALL be
repeated as rfc822Name or otherName values of type id-on-SmtpUTF8Mailbox in this
extension.
7.1.4.2.2 Subject distinguished name fields
h.
BRs: 7.1.2.3c
CA Certificate Authority Information Access
The authorityInformationAccess extension MAY contain one or more accessMethod
values for each of the following types:
id-ad-ocsp specifies the URI of the Issuing CA's OCSP responder.
BRs: 7.1.2.3c
CA Certificate Authority Information Access
The authorityInformationAccess extension MAY contain one or more accessMethod
values for each of the following types:
id-ad-ocsp specifies the URI of the Issuing CA's OCSP responder.
BRs: 7.1.2.3c
CA Certificate Authority Information Access
The authorityInformationAccess extension MAY contain one or more accessMethod
values for each of the following types:
id-ad-ocsp specifies the URI of the Issuing CA's OCSP responder.
"RFC5280: RFC 4055, Section 1.2"
RSA: Encoded algorithm identifier MUST have NULL parameters.
BRs: 7.1.2.2c
This extension SHOULD be present.
CAB 7.1.2.2c
With the exception of stapling, which is noted below, this extension MUST be present.
CAB BR 1.7.1 Section 7.1.2.2c - authorityInformationAccess
This extension SHOULD be present.
BRs: 7.1.2.2a certificatePolicies
This extension MUST be present and SHOULD NOT be marked critical.
BRs: 7.1.2.2a certificatePolicies
This extension MUST be present and SHOULD NOT be marked critical.
BRs: 7.1.2.2b cRLDistributionPoints
This extension MUST be present and MUST NOT be marked critical.
BRs: 7.1.2.2b cRLDistributionPoints
This extension MUST be present and MUST NOT be marked critical.
BRs: 7.1.2.2b cRLDistributionPoints
This extension MUST be present and MUST NOT be marked critical.
BRs: 7.1.2.2g extkeyUsage (optional)
For Subordinate CA Certificates to be Technically constrained in line with section 7.1.5, then either the value
id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present.
CA Brower Forum Baseline Requirements, Section 7.1.2.2:
f. nameConstraints (optional)
If present, this extension SHOULD be marked critical*.
BRs: 7.1.2.10.3
CA Certificate Authority Information Access
This extension MAY be present.
BRs: 7.1.2.3
cRLDistributionPoints
This extension MAY be present.
BRs: 7.1.2.3
authorityInformationAccess
This extension MUST be present.
BRs: 7.1.2.3
authorityInformationAccess
With the exception of stapling, which is noted below, this extension MUST be present.
CA/Browser Forum BRs: 7.1.2.7.6 Subscriber Certificate Extensions
| __Extension__ | __Presence__ | __Critical__ | __Description__ |
| ---- | - | - | ----- |
| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-subscriber-certificate-basic-constraints) |
BRs: 7.1.2.3
certificatePolicies
This extension MUST be present and SHOULD NOT be marked critical.
BRs: 7.1.2.3
certificatePolicies
This extension MUST be present and SHOULD NOT be marked critical.
BRs: 7.1.2.3
cRLDistributionPoints
This extension MAY be present.
BRs: 7.1.2.3
cRLDistributionPoints
This extension MAY be present.
BRs: 7.1.2.3
extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or
both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present.
BRs: 7.1.2.3
extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or
both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present.
BRs: 7.1.2.3
extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or
both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present.
BRs: 7.1.2.3
keyUsage (optional)
If present, bit positions for keyCertSign and cRLSign MUST NOT be set.
BRs: 7.1.2.3
keyUsage (optional)
If present, bit positions for keyCertSign and cRLSign MUST NOT be set.
BRs: 7.1.3
SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.
Effective 16 January 2015, CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with
an Expiry Date greater than 1 January 2017 because Application Software Providers are in the process of
deprecating and/or removing the SHA-1 algorithm from their software, and they have communicated that
CAs and Subscribers using such certificates do so at their own risk.
BRs: 7.1.4.2.2
Required/Optional: Deprecated (Discouraged, but not prohibited)
BRs: 7.1.2.7.1
Required/Optional: NOT RECOMMENDED
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-common-name INTEGER ::= 64
If present, this field MUST contain exactly one entry that is one of the values contained
in the Certificate's `subjectAltName` extension
If the [subject:commonName] is a Fully-Qualified Domain Name or Wildcard Domain Name, then
the value MUST be encoded as a character-for-character copy of the dNSName entry value from
the subjectAltName extension.
BRs: 7.1.4.2.2
If present, this field MUST contain a single IP address
or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1).
BRs: 7.1.4.2.2
Other Subject Attributes
With the exception of the subject:organizationalUnitName (OU) attribute, optional attributes, when present within
the subject field, MUST contain information that has been verified by the CA.
BRs: 7.1.4.2.2
Certificate Field: subject:organizationalUnitName (OID: 2.5.4.11)
Required/Optional: Deprecated.
BRs: 7.1.4.2.2
Certificate Field: issuer:countryName (OID 2.5.4.6)
Required/Optional: Required
Contents: This field MUST contain the two-letter ISO 3166-1 country code for the country in which the issuer’s
place of business is located.
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-emailaddress-length INTEGER ::= 128
The ASN.1 modules in Appendix A are unchanged from RFC 3280, except
that ub-emailaddress-length was changed from 128 to 255 in order to
align with PKCS #9 [RFC2985].
RFC 5280: 4.2 & 4.2.1.6
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present.
RFC 5280: A.1
-- Naming attributes of type X520name
id-at-givenName AttributeType ::= { id-at 42 }
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds
-- Upper Bounds
ub-name INTEGER ::= 32768
RFC 5280: A.1
-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds
The subject information access extension indicates
how to access information and services for the subject
of the certificate in which the extension appears.
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-locality-name INTEGER ::= 128
RFC 5280: 4.1.2.6
Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN).
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-organizational-unit-name INTEGER ::= 64
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-organization-name INTEGER ::= 64
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-postal-code-length INTEGER ::= 16
RFC 5280: A.1
In this Appendix, there is a list of upperbounds
for fields in a x509 Certificate. *
ub-state-name INTEGER ::= 128
ITU-T X.520 (02/2001) UpperBounds
ub-street-address INTEGER ::= 128
RFC 5280: A.1
-- Naming attributes of type X520name
id-at-surname AttributeType ::= { id-at 4 }
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds
-- Upper Bounds
ub-name INTEGER ::= 32768
RFC 5280: A.1
-- specifications of Upper Bounds MUST be regarded as mandatory
-- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
-- Upper Bounds
CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate validity
dates in 2050 or later MUST be encoded as GeneralizedTime.