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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
