Please consider to add support for Intermediate Authority TLSA RR Type. Please correct & improve below paragraphs. Thanks in advance.
In RFC 6698 https://tools.ietf.org/html/rfc6698 Section 7.2 is showing list of TLSA Certificate Usages, 4-254 Unassigned. And showing "Applications to the registry can request specific values that have yet to be assigned." - - - - - - - - - - - - - - - 2.1.1. The Certificate Usage Field : TLSA Usage 4: Certificate usage 4 is used to specify one or more Intermediate Authority certificate, or the public key of such certificates, which MUST be used as intermediate trust anchor when validating the end entity certificate given by the server in TLS. This certificate usage is sometimes referred to as "intermediate trust anchors" (ITA) or "intermediate authority anchors" (IA). When TLSA Usage 2 is used for the domain, then TLSA Usage 4 allows domain name administrator to specify new, one or more intermediate trust anchors (ITA / IA). When TLSA Usage 0 is used, then TLSA Usage 4 allows to specify one or more pre-existing intermediate or subordinate CA. For example, TLSA Usage 4 is used when the domain issues its own one or more intermediate certificate under a CA or under a new Trust Anchor (TA) that may or may not exist in end user' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a intermediate trust anchor for this certification path validation. - - - - - - - - - - - - - - - In RFC 6698 https://tools.ietf.org/html/rfc6698 Section 7.3 is showing list of TLSA Selectors, 2-254 Unassigned. And showing "Applications to the registry can request specific values that have yet to be assigned." - - - - - - - - - - - - - - - 2.1.2. The Selector Field: 64 -- Full Intermediate certificate: the (full) intermediate authority (IA) certificate, at level-1, which issued the End Entity certificate, MUST have selector value 64. The IA certificate at level-2 will use selector value 65 and third full IA will use selector value 66, and so on, upto 74. The Certificate binary structure as defined in [RFC5280] 128 -- SubjectPublicKeyInfo: the intermediate authority (IA) certificate, at level-1, which issued the End Entity certificate, MUST have selector value 128. The IA certificate at level-2 will use selector value 129 and third IA will use selector value 130, and so on, upto 138. DER-encoded binary structure as defined in [RFC5280] - - - - - - - - - - - - - - - So this will allow ( 74 - 64 = ) upto 10 intermediate trust anchors or intermediate CA. Selector values 64 - 74 are for FULL TLS certificates. And selector values 128 - 138 are for specifying intermediate certificate's SubjectPublicKeyInfo data portion. And quoting from Section A.1.2.2. : "Using the SubjectPublicKeyInfo selector for association with a certificate in a chain above I1 needs to be decided on a case-by-case basis: there are too many possibilities based on the issuing CA's practices. Unless the full implications of such an association are understood by the administrator, using selector type 0 is a better option from a security perspective." - - - - - - - - - - - - - - - And, using selector type from 64 to 74 for intermediate certificates, is a better option for declaring intermediate certificates. - - - - - - - - - - - - - - - And pls also consider to create such a section: - - - - - - - - - - - - - - - A.1.2.3. Selector Type 64-74 & 128-138 (Intermediate Certificate) For an example, if such certificate chain is used for a domain: EE <-- IA-B <-- IA-A <-- CA/TA. It can also be represented in this form: Level-0 <- Level-1 <- Level-2 <- Level-3. Then, TLSA RR examples: EE, end entity, Level-0 certificate: _443._tcp.www.example.com. IN TLSA ( 1 0 0 30820307308201efa003020102020... ) IA-B, second intermediate authority certificate, which signed the EE certificate, at level-1: _443._tcp.www.example.com. IN TLSA ( 64 0 0 30820454308202BC020900AB58D... ) IA-A, first intermediate authority certificate, at Level-2: _443._tcp.www.example.com. IN TLSA ( 127 0 0 8755CDAA8FE24EF16CC0F2C9180... ) TA root certificate, at Level-3: _443._tcp.www.example.com. IN TLSA ( 2 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) or, CA root certificate, at Level-3: _443._tcp.www.example.com. IN TLSA ( 0 0 0 D2ABDE240D7CD3EE6B4B28C54DF... ) - - - - - - - - - - - - - - - why such options were not added ? What pros and cons ? -- Bright Star.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
