You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a big list of unsorted, unprioritised issues found from x509test cases. I'm not making any particular claim that these are important issues, or even issues we want to fix. For example, some of the RFC assertions are requirements on issuers, not verifiers.
duplicate extensions are not rejected for extensions webpki does not support
RFC5280 s4.2 'A certificate MUST NOT include more than one instance of a particular extension'
xf_duplicate_extension
xf_duplicate_extension2
illegal subjectAltName extensions not rejected
RFC5280 s4.2.1.6 'If the subjectAltName extension is present, the sequence MUST contain at least one entry'
xf_ext_altname_empty
RFC5280 s4.2.1.6 'conforming CAs MUST NOT issue certificates with subjectAltNames containing empty GeneralName fields'
xf_ext_altname_empty2
RFC5280 s4.2.1.6 'subjectAltName extensions with a dNSName of ' ' MUST NOT be used'
xf_ext_altname_blank_domain
RFC5280 s4.2.1.6 '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'
xf_ext_altname_email_only
RFC5280 s4.2.1.6 'the address MUST be stored in the rfc822Name. The format of an rfc822Name is a Mailbox as defined in Section 4.1.2 of [RFC2821]. A Mailbox has t he form Local-part@Domain'
xf_ext_altname_invalid_email
RFC5280 s4.2.1.6 'For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC2460], the octet string MUST contain exactly sixteen octets'
xf_ext_altname_ip_wrong
RFC5280 s4.2.1.6 'If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical.'
xf_ext_altname_noncrit_nosubj
empty OID is not rejected inside extKeyUsage extension
RFC5280 s4.2.1.12 'ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId'
xf_ext_extended_key_usage_empty_oid
certain CA-only extensions not rejected if basic constraints cA=false
RFC5280 s4.2.1.3 'If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted'
xf_ext_keysign_nonca
RFC5280 s4.2.1.10 'The name constraints extension ... MUST be used only in a CA certificate'
xf_ext_name_constraints_nonca
end entity subject public key validation seems not to happen during parsing/chain/name validation -- (maybe that is deferred to verify_signature? in which case ignore these)
xf_der_pubkey_rsa_nonminimal_int
xf_pubkey_ecdsa_not_on_curve
xf_pubkey_ecdsa_secp192r1
xf_pubkey_ecdsa_unknown_curve
xf_pubkey_rsa_exponent_negative
xf_pubkey_rsa_modulus_negative
xf_pubkey_rsa_param_nonnull
missing validations during trust anchor parsing(?)
RFC5280 s4.2.1.10 'For IPv4 addresses, the iPAddress field of GeneralName MUST contain eight (8) octets'
xf_ext_name_constraints_badip
RFC5280 s4.2.1.10 'Conforming CAs MUST NOT issue certificates where name constraints is an empty sequence.'
xf_ext_name_constraints_empty
RFC5280 s4.2.1.10 'Conforming CAs MUST mark this extension as critical'
xf_ext_name_constraints_noncrit
RFC5280 s4.2.1.10 'the minimum MUST be zero, and maximum MUST be absent'
xf_ext_name_constraints_minmax
RFC5280 s4.2.1.2 'this extension MUST appear in all conforming CA certificates'
xf_ext_subject_keyid_ca_absent
comparison of string encodings in subject/issuer
RFC5280 s7.1 'Conforming implementations MUST use ...RFC4518 as the basis for comparison of distinguished name attributes encoded in either PrintableString or UTF8String.'
ok_issuer_asn1_differ
optional subjectUniqueID causes parse failure
parsing of extensions (context[3]) fails rather than jumping over subjectUniqueID (context[2])
ok_uniqueid_incomplete_byte
policy constraint extension (probably no advantage to implementing this, but listed here for completeness)
RFC5280 s4.2 'applications conforming to this profile MUST recognize the following extensions: ...policy constraints (Section 4.2.1.11)'
ok_ext_policy_constraints
The text was updated successfully, but these errors were encountered:
This is a big list of unsorted, unprioritised issues found from x509test cases. I'm not making any particular claim that these are important issues, or even issues we want to fix. For example, some of the RFC assertions are requirements on issuers, not verifiers.
duplicate extensions are not rejected for extensions webpki does not support
illegal subjectAltName extensions not rejected
empty OID is not rejected inside extKeyUsage extension
certain CA-only extensions not rejected if basic constraints cA=false
end entity subject public key validation seems not to happen during parsing/chain/name validation -- (maybe that is deferred to
verify_signature
? in which case ignore these)missing validations during trust anchor parsing(?)
comparison of string encodings in subject/issuer
optional subjectUniqueID causes parse failure
policy constraint extension (probably no advantage to implementing this, but listed here for completeness)
The text was updated successfully, but these errors were encountered: