[Trans] Goals and generic mis-issuance fgramework

[Stephen Kent <[e-mail]>]

In response to some of the issues Paul and others have raised, I have 
generated
some text that tries to characterize the goal of CT, establishes a 
generic framnework
for defining checks for mis-issuance, and sets the stage for references 
to two RFcs
that will define syntactic and semantic checks for Web PKI certs 
claiming to conform to
CABF DV or EV guidelines.

Note that this text do not require a log to perform any checks; it 
allows a log to
indicate if has performed applicable checks, and the results of such 
checking.

Steve
-------

1. Certificate Transparency Goals and Mechanisms

The goals of Certificate Transparency (CT) are threefold: detection, 
deterrence, and enabling remediation of mis-issuance of certificates. 
The initial focus of CT is the Web PKI context, (The Web PKI context 
refers to the use of a set of Certification Authorities (CAs) that issue 
X.509 certificates to web servers to enable TLS-protected access by 
clients [cite WPKOPS?].) In the future, it is anticipated that addition 
operational contexts may be supported. As a result, mis-issuance is 
defined in an fashion that accommodates a range of types of certificates 
used in a range of contexts.

CT supports detection of mis-issuance using logs of certificates, 
populated by the CAs that issue them or by the Subjects of certificates. 
Monitors (described in Section *X*) are the primary elements of the CT 
system that check certificates for syntactic and semantic mis-issuance, 
on behalf of Subjects. A Monitor may be operated by a third party on 
behalf of Subjects, or may be operated by a Subject on its own behalf. 
(The latter is referred to as "self-monitoring".) Logs may optionally 
perform syntactic checks for some classes of certificates, but a log is 
not required to offer certificate checking.

A certificate mis-issued by a CA, and detected by the CT system, is 
presumed to damage the reputation of the CA. Thus it is anticipated that 
CT will deter mis-issuance via monitoring of logs. It also is 
anticipated that CT also will help remedy mis-issuance, in two ways. 
When a mis-issued certificate is detected as such, the Subject will be 
notified. The Subject can contact the issuer and request revocation of 
the bogus certificate, using information from the log.

A certificate is characterized as mis-issued if the certificate does not 
conform to requirements established for the class of certificate in 
question. The term "class" refers to certificates used in different 
application contexts and issued under different sets of syntactic and 
semantic guidelines. Thus, for example, most certificates used in the 
Web PKI context are issued by CAs under guidelines published by the CA 
Browser Forum (CABF). (If a new version of guidelines is created for a 
class of certificates, a new certificate class ID (CCID) will be 
assigned. This allows certificates issued under old and new sets of 
guidelines to be checked appropriately, without introducing ambiguity.) 
Certificates used with IPsec, S/MIME, or other security protocols each 
constitute a different class. A certificate that is not issued in 
accordance with any published set of requirements is assigned a reserved 
CCID.

To enable Monitors (and, optionally, logs) to perform an appropriate set 
of checks, the (pre-) a CCID MUST be provided to a log when a 
certificate is submitted by a CA or Subject. This CCID MUST appear in 
the log entry and in the SCT generated by the log. By providing the CCID 
in logs and SCTs, both Monitors and clients are empowered to perform 
applicable checks based on the certificate class asserted by the CA or 
Subject.

This document establishes an IANA registry of CCIDs (see Section *Y*) to 
enable CT to deal with additional classes of certificates in the future. 
The registry is initially populated with CCIDs deemed appropriate for 
the Web PKI context (see Section *Y*). Every registry entry lists the 
RFC (or analogous document) that specifies the checks applicable to the 
registered certificate class. One entry is established to indicate a 
CCID for which no applicable checks have been defined.

Mis-issuance

Mis-issuance takes two primary forms: syntactic mis-issuance and 
semantic mis-issuance.

1.A certificate may fail to meet the syntactic constraints established 
for a specified certificate class. Such failure can have serious 
security implications, e.g., a failure to include the basicConstrainst 
extension in a Web PKI certificate can allow the holder of an EE 
certificate to issue subordinate certificates that may be accepted by 
browsers. Most syntactic constraints can be checked via examination of a 
certificate chain, without reference to Subject-specific or CA-specific 
data. This means that these constraints can be verified by logs without 
access to Subject-specific data.

2.A certificate may fail to meet the semantic constraints established 
for a specified certificate class. The usual (though not universal) 
semantic constraint is that a certificate is issued only to an entity 
that is authorized to represent the Subject name (subjectAltName) in the 
certificate. This constraint can be verified by comparing a certificate 
against the set of "reference" certificates supplied by a Subject. In 
the Web PKI context, the Subject (subjectAltName) represents a web 
server, and the entity to which the certificate is issued is presumed to 
be authorized by the owner of the corresponding DNS name. For other 
classes of certificates, the relevant name might be an IP address, an 
e-mail address, or some other identifier appropriate to the application 
context in which the certificate is used.

A log MAY perform the syntactic checks consistent with the certificate 
class asserted by the CA or Subject that submits a (pre-) certificate to 
the log. This behavior is RECOMMENDED to provide timely feedback to CAs 
and Subjects when certificates are submitted to logs. For a CA it can 
detect potential syntactic mis-issuance before a certificate is issued. 
For a Subject, it provides an indication of whether its certificate 
conforms to the asserted criteria. A log MUST include the asserted 
certificate class ID in the log entry.

A log MUST generate a Syntax Verification Value (SVV) for the 
certificate, and include the SVV in the log entry and in the SCT.

The LVV is value specified by this document (see Section Z) that 
indicates whether or not the log performed applicable syntactic checks, 
and whether the (pre-) certificate passed of failed the checks. Although 
it is anticipated that new certificate classes will arise over time, the 
set of log actions with respect to syntax checking appears to be 
well-defined and thus need not be represented in an IANA registry. Each 
SCT issued by a log MUST include an SVV.

A Monitor also may perform syntactic checks of certificates. It may do 
so because a certificate was not checked by a log (as indicated in the 
log entry), or as a way to detect logs that have been compromised or 
that are deficient or malicious.

Detection of semantic mis-issuance requires access to one or more 
"reference" certificates associated with a specified Subject. (For 
purposes of this discussion, a reference certificate is a valid 
certificate issued to a specified Subject, consistent with the 
guidelines specified by the certificate class ID.) As noted above, the 
primary attack addressed by detection of semantic mis-issuance is 
issuance of a certificate to an entity that is not authorized to 
represent the host (web server) named in the certificate Subject field 
(or subjectAltName extension).

Section *Y.* IANA Registry for Certificate Class Identifiers (CCIDs)

The name of the registry shall be "Certificate Class Identifiers for use 
with Certificate Transparency",

This is a "Standards Action" registry.Each registry entry consists of a 
positive integer (16-bit) and a reference to the RFC that defines the 
syntactic and semantics checks applicable to the certificate class 
identified by the integer. The first entry "0" designates a certificate 
class for which no syntactic or semantic checks are defined.

The following initial entries are created by this RFC:

ValueRFC

0N/A

1XXXX (certificate checks derived from [CABF-DV])

2XXXX (certificate checks derived from [CABF-EV])

Section Z. Syntax Verification Value (SVV) Definitions

The following integer (8-bit) values are defined for the Syntax 
Verification Values (SVVs) generated by a log.

ValueInterpretation

0The CCID value was 0, so not checks were performed

1This log does not perform syntax checks

2This log does not support syntax checks for the asserted CCID

3This log performed the syntax checks for the asserted CCID, and the 
certificate passed

4This log performed the syntax checks for the asserted CCID, and the 
certificate failed

No other SVV values are defined by this RFC.