Deviations from RFC 5280

[djc]

Originally filed by @ctz as briansmith/webpki#256, making a clone here since it seems useful.

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 failures

  • 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