# Appendix A High risk regions of concern The geographic locations listed below have more than 5% of the Code Signing Certificates for that location associated with signed Suspect Code when compared to the number of all Code Signing Certificates for that area. Applications originating or associated from one of these HRRCs are considered high risk and require additional verification as specified under [Section 4.2.2](#422-approval-or-rejection-of-certificate-applications) of this document: NONE

EVG

# Appendix A - User Agent Verification (Normative) The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are: i. valid; ii. revoked; and iii. expired.

SMIME

# Appendix A - Registration schemes

TLS

# Appendix A – CAA Contact Tag These methods allow domain owners to publish contact information in DNS for the purpose of validating domain control.

SMIME

## A.1 organizationIdentifier The following Registration Schemes are recognized as valid under these Requirements for use in the `subject:organizationIdentifier` attribute described in [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields), in addition to the GOV and INT identifiers described therein. * **NTR**: For an identifier allocated by a national or state trade register to the Legal Entity named in the `subject:organizationName`. * **VAT**: For an identifier allocated by the national tax authorities to the Legal Entity named in the `subject:organizationName`. * **PSD**: For a national authorization number allocated to the payment service provider named in the `subject:organizationName` under Payments Services Directive (EU) 2015/2366. This shall use the extended structure as defined in ETSI TS 119 495, clause 5.2.1. * **LEI**: For a Legal Entity Identifier as specified in ISO 17442 for the entity named in the `subject:organizationName`. The 2 character ISO 3166-1 country code SHALL be set to 'XG'.

TLS

## A.1. CAA Methods

SMIME

## A.2 Natural Person Identifier The following Registration Schemes are recognized as valid for use in the `subject:serialNumber` attribute described in [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields). * **PAS**: For an identifier based on a passport number issued to the Subject Individual. * **IDC**: For an identifier based on a national identity card issued to the Subject Individual. * **PNO**: For an identifier based on a national personal number (or national civic registration number) issued to the Subject Individual. * **TAX**: For an identifier based on a personal tax reference number issued by a national tax authority. * **TIN**: For an identifier based on Tax Identification Number issued to the Subject Individual according to the [European Commission - Tax and Customs Union](https://ec.europa.eu/taxation_customs/tin/tinByCountry.html). * **EID**: For an identifier based on electronic identification means (e.g., national eID or EU wallet)

TLS

## A.2. DNS TXT Methods

TLS

### A.1.1. CAA contactemail Property SYNTAX: `contactemail ` The CAA contactemail property takes an email address as its parameter. The entire parameter value MUST be a valid email address as defined in [RFC 6532, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6532#section-3.2), with no additional padding or structure, or it cannot be used. The following is an example where the holder of the domain specified the contact property using an email address. ```DNSZone $ORIGIN example.com . CAA 0 contactemail "domainowner@example.com" ``` The contactemail property MAY be critical, if the domain owner does not want CAs who do not understand it to issue certificates for the domain.

TLS

### A.1.2. CAA contactphone Property SYNTAX: `contactphone ` The CAA contactphone property takes a phone number as its parameter. The entire parameter value MUST be a valid Global Number as defined in [RFC 3966, Section 5.1.4](https://datatracker.ietf.org/doc/html/rfc3966#section-5.1.4), or it cannot be used. Global Numbers MUST have a preceding + and a country code and MAY contain spaces as visual separators. The following is an example where the holder of the domain specified the contact property using a phone number. ```DNSZone $ORIGIN example.com . CAA 0 contactphone "+1 555 123 4567" ``` The contactphone property MAY be critical if the domain owner does not want CAs who do not understand it to issue certificates for the domain.

TLS

### A.2.1. DNS TXT Record Email Contact The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid email address as defined in [RFC 6532, Section 3.2](https://datatracker.ietf.org/doc/html/rfc6532#section-3.2), with no additional padding or structure, or it cannot be used.

TLS

### A.2.2. DNS TXT Record Phone Contact The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in [RFC 3966, Section 5.1.4](https://datatracker.ietf.org/doc/html/rfc3966#section-5.1.4), or it cannot be used.