Subject: [Trans] Goals and generic mis-issuance fgramework

From: Stephen Kent <[email-masked]>
Date: Thu, 09 Oct 2014 17:20:56 -0400

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.

---

From: Rick Andrews <[email-masked]>
Date: Mon, 20 Oct 2014 14:38:02 -0700

Stephen,

Some comments inline.

-Rick

From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, October 09, 2014 2:21 PM
To: [email-masked]
Subject: [Trans] Goals and generic mis-issuance fgramework

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
-------

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 *additional* 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.
The first sentence needs to be more broad, since anyone can send a cert to a log. But it's most likely to be the CAs or the Subjects, so I would suggest "CT supports detection of mis-issuance using logs of certificates, populated by the CAs that issue them, by the Subjects of certificates, or by anyone with knowledge of the entire certificate chain.".

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.
Hmm... Since anyone can send a cert to a log, the first sentence must reflect that. But that makes me wonder what should happen if the "Reporter" (I don't want to introduce a new role) sends the wrong CCID? (By "wrong" I mean it's a valid CCID, but it's not the one that the CA would associate with the cert.) Or sends the cert multiple times with different CCIDs? I guess Monitors would have to expect multiple entries for a given certificate in a given log, with different CCIDs. I'm not sure if 6962-bis imposes any uniqueness constraint that this might violate.

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 *SVV* is *a* 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 *or* 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.

Value Interpretation

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

1                 This log does not perform syntax checks

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

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

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2014 11:46:02 -0400

Rick,

Thanks for the comments.

> 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 **additional** 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.
>
> 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.
>
> The first sentence needs to be more broad, since anyone can send a 
> cert to a log. But it's most likely to be the CAs or the Subjects, so 
> I would suggest "CT supports detection of mis-issuance using logs of 
> certificates, populated by the CAs that issue them, by the Subjects of 
> certificates, or by anyone with knowledge of the entire certificate 
> chain.".
>

I'll use your text here, thanks.
>
> 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 
> 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.
>
> Hmm... Since anyone can send a cert to a log, the first sentence must 
> reflect that. But that makes me wonder what should happen if the 
> "Reporter" (I don't want to introduce a new role) sends the wrong 
> CCID? (By "wrong" I mean it's a valid CCID, but it's not the one that 
> the CA would associate with the cert.) Or sends the cert multiple 
> times with different CCIDs? I guess Monitors would have to expect 
> multiple entries for a given certificate in a given log, with 
> different CCIDs. I'm not sure if 6962-bis imposes any uniqueness 
> constraint that this might violate.
>
Thanks for catching the typo. If a (pre-) cert is submitted with a CCID 
that is inappropriate
for the cert type, then there can be several outcomes, depending on the 
nature of the error and the log operation. If a cert class not yet 
accepted by the log, the log will not try to check it, and it will be 
marked that way.

If the log does check the CCID in question, the cert may fail (but will 
still be logged) because the wrong syntactic checks were applied. The 
CA/Subject/other will get immediate feedback on that, which might cause 
re-sumbission to the log, with the right CCID.

If the same cert is sent multiple times, with different CCIDS, this is 
something a Monitor will notice, if it's protecting the name in the cert 
in nquestion. The Subject should be notified of this anomalous behavior.

An Auditor might note this behavior as well; we'll see when we have a 
concrete description of the functions that an Auditor performs.

In any case, I don't see the multiple CCID situation as a problem for 
CT; it does provide more info to those watching logs. Since the same 
cert may be submitted to a log by multiple entities (CA, Subject, nosy 
3rd party) already, I don't see any uniqueness constraint issues from 
6962-bis.
> The LVV**SVV**is **a** 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 **or** 
> 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.
>
thanks again for catching that typo too. Santosh also noted this in a 
message to me.
>
> Value Interpretation
>
> 0The CCID value was 0, so not **no** checks were performed
>
Again, thanks for catching this typo.

Steve

---

From: Russ Housley <[email-masked]>
Date: Sat, 25 Oct 2014 13:01:06 -0400

Steve and Rick:

> 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 *additional*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.
> The first sentence needs to be more broad, since anyone can send a cert to a log. But it’s most likely to be the CAs or the Subjects, so I would suggest “CT supports detection of mis-issuance using logs of certificates, populated by the CAs that issue them, by the Subjects of certificates, or by anyone with knowledge of the entire certificate chain.”.

Can't anyone build the certificate chain?  Since the logs are posting the supported trust anchors, anyone can build a chain for the end entity certificate.

> Hmm… Since anyone can send a cert to a log, the first sentence must reflect that. But that makes me wonder what should happen if the “Reporter” (I don’t want to introduce a new role) sends the wrong CCID? (By “wrong” I mean it’s a valid CCID, but it’s not the one that the CA would associate with the cert.) Or sends the cert multiple times with different CCIDs? I guess Monitors would have to expect multiple entries for a given certificate in a given log, with different CCIDs. I’m not sure if 6962-bis imposes any uniqueness constraint that this might violate.  

Alternatively, a log could check to see if the reported certificate is already present, and if so, return the older entry to the party that reports the certificate.  I seem to recall reading this idea at some point, buy I admit I did not look into the current I-D to see if that was where i read it.

> No other SVV values are defined by this RFC.

If the log performs some validation checks, are you suggesting that a relying party can leverage the work already done by the log?  If so, it puts the log checking at a different place in the certificate validation than I was imagining.

Russ

---

From: Rick Andrews <[email-masked]>
Date: Mon, 27 Oct 2014 15:32:37 -0700

Russ, comments inline.

-Rick

From: Trans [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, October 25, 2014 10:01 AM
To: Rick Andrews; Steve Kent
Cc: [email-masked]
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

Steve and Rick:

[Rick] In most cases, yes. If someone has access to the server configured with that certificate, they can do a TLS handshake and get the chain in nearly all cases. We see some web servers that are missing the intermediate CA cert, and some browsers (IE, for example) will follow the AIA extension (if it's in the cert) and fetch the intermediate. Any client can do that too. But if the CA didn't put an AIA extension in the cert and you can't find a server with that cert, it might not be possible to find the intermediate CA cert. And without the intermediate (or intermediates!) the log won't accept it.

Alternatively, a log could check to see if the reported certificate is already present, and if so, return the older entry to the party that reports the certificate.  I seem to recall reading this idea at some point, buy I admit I did not look into the current I-D to see if that was where i read it.
[Rick] RFC 6962 and bis-04 say "If the log has previously seen the certificate, it MAY return the same SCT as it returned before." But this would have to be expanded to say "If the log has previously seen the certificate and CCID, it MAY return the same SCT as it returned before." It's a bit more complex, since the log server may not support the CCID or any checking, in which cases it would always log the entry with CCID =1 that indicates "This log does not perform syntax checks", or CCID=2 that indicates "This log does not support syntax checks for the asserted CCID".

Value Interpretation

If the log performs some validation checks, are you suggesting that a relying party can leverage the work already done by the log?  If so, it puts the log checking at a different place in the certificate validation than I was imagining.
[Rick] Yes, a relying party could leverage the work already done by the log server, if the RP trusted it. Google would probably advise against this, since they have been pretty consistent in saying that CT doesn't require you to trust anyone including the log server.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 28 Oct 2014 02:09:39 +0000

Relying parties relying on the checks made by log server may be problematic if both do not have the same trust store if the initialization variables are different.

My primary motivation in log doing checks is nip the problem in the bud and reduce the probability of relying parties having to decide on exceptions.  The relying parties still should validate the certification path.

From: Trans [mailto:[email-masked]] On Behalf Of Rick Andrews
Sent: Monday, October 27, 2014 6:33 PM
To: Russ Housley; Steve Kent
Cc: [email-masked]
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

Russ, comments inline.

-Rick

Cc: [email-masked]<mailto:[email-masked]>

Steve and Rick:

Value Interpretation

---

From: Eran Messeri <[email-masked]>
Date: Tue, 28 Oct 2014 16:45:56 +0000

Overall the mechanism described seems reasonable. Can you help me
understand the benefits from the TLS client's perspective?
IIUC, the log will never refuse to include a certificate, it will merely
indicate it failed syntactic checks.
Are you suggesting that TLS clients will reject an otherwise-valid
certificate chain which has a CCID that matches the TLS client's desired
use of the certificate, because the log indicated it failed syntactic
checks?

It's not a bad thing, it does place additional burden on logs though.
Monitors will have to verify the log's honest behaviour on this aspect as
well.

The other question is - aren't certificate classes different enough to
merit running different logs, where the log's identity (or some other
metadata) indicates which CCID it's good for?
I'm a bit weary of specifying a behaviour for the general case where I
don't have concrete examples for more than one particular case.

On Tue, Oct 28, 2014 at 2:09 AM, Santosh Chokhani <[email-masked]>
wrote:

>  Relying parties relying on the checks made by log server may be
> problematic if both do not have the same trust store if the initialization
> variables are different.
>
>
>
> My primary motivation in log doing checks is nip the problem in the bud
> and reduce the probability of relying parties having to decide on
> exceptions.  The relying parties still should validate the certification
> path.
>
>
>
> *From:* Trans [mailto:[email-masked]] *On Behalf Of *Rick Andrews
> *Sent:* Monday, October 27, 2014 6:33 PM
> *To:* Russ Housley; Steve Kent
>
> *Cc:* [email-masked]
> *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework
>
>
>
> Russ, comments inline.
>
>
>
> -Rick
>
>
>
> *From:* Trans [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Russ Housley
> *Sent:* Saturday, October 25, 2014 10:01 AM
> *To:* Rick Andrews; Steve Kent
> *Cc:* [email-masked]
> *Subject:* Re: [Trans] Goals and generic mis-issuance fgramework
>
>
>
> Steve and Rick:
>
>
>
>
>
> 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 **additional**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.
>
>
>
> 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.
>
> The first sentence needs to be more broad, since anyone can send a cert to
> a log. But it’s most likely to be the CAs or the Subjects, so I would
> suggest “CT supports detection of mis-issuance using logs of certificates,
> populated by the CAs that issue them, by the Subjects of certificates, or
> by anyone with knowledge of the entire certificate chain.”.
>
>
>
> Can't anyone build the certificate chain?  Since the logs are posting the
> supported trust anchors, anyone can build a chain for the end entity
> certificate.
>
>
>
> [Rick] In most cases, yes. If someone has access to the server configured
> with that certificate, they can do a TLS handshake and get the chain in
> nearly all cases. We see some web servers that are missing the intermediate
> CA cert, and some browsers (IE, for example) will follow the AIA extension
> (if it’s in the cert) and fetch the intermediate. Any client can do that
> too. But if the CA didn’t put an AIA extension in the cert and you can’t
> find a server with that cert, it might not be possible to find the
> intermediate CA cert. And without the intermediate (or intermediates!) the
> log won’t accept it.
>
>
>
> 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.
>
> Hmm… Since anyone can send a cert to a log, the first sentence must
> reflect that. But that makes me wonder what should happen if the “Reporter”
> (I don’t want to introduce a new role) sends the wrong CCID? (By “wrong” I
> mean it’s a valid CCID, but it’s not the one that the CA would associate
> with the cert.) Or sends the cert multiple times with different CCIDs? I
> guess Monitors would have to expect multiple entries for a given
> certificate in a given log, with different CCIDs. I’m not sure if 6962-bis
> imposes any uniqueness constraint that this might violate.
>
>
>
> Alternatively, a log could check to see if the reported certificate is
> already present, and if so, return the older entry to the party that
> reports the certificate.  I seem to recall reading this idea at some point,
> buy I admit I did not look into the current I-D to see if that was where i
> read it.
>
> [Rick] RFC 6962 and bis-04 say “If the log has previously seen the
> certificate, it MAY return the same SCT as it returned before.” But this
> would have to be expanded to say “If the log has previously seen the
> certificate *and CCID*, it MAY return the same SCT as it returned
> before.” It’s a bit more complex, since the log server may not support the
> CCID or any checking, in which cases it would always log the entry with
> CCID =1 that indicates “This log does not perform syntax checks”, or CCID=2
> that indicates “This log does not support syntax checks for the asserted
> CCID”.
>
>
>
>
>
> 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 **SVV** is **a** 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 **or** 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.
>
>
>
>
>
> Value Interpretation
>
> 0                 The CCID value was 0, so not **no** checks were
> performed
>
> If the log performs some validation checks, are you suggesting that a
> relying party can leverage the work already done by the log?  If so, it
> puts the log checking at a different place in the certificate validation
> than I was imagining.
>
> [Rick] Yes, a relying party could leverage the work already done by the
> log server, if the RP trusted it. Google would probably advise against
> this, since they have been pretty consistent in saying that CT doesn’t
> require you to trust anyone including the log server.
>
>
>
>
>
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Rick Andrews <[email-masked]>
Date: Tue, 28 Oct 2014 10:21:28 -0700

Eran, there may be no direct benefits to the TLS client, but indirect benefits could accrue if CAs don’t issue cert that fail a log’s syntactic checks.

-Rick

From: Eran Messeri [mailto:[email-masked]]
Sent: Tuesday, October 28, 2014 9:46 AM
To: Santosh Chokhani
Cc: Rick Andrews; Russ Housley; Steve Kent; [email-masked]
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

Overall the mechanism described seems reasonable. Can you help me understand the benefits from the TLS client's perspective?
IIUC, the log will never refuse to include a certificate, it will merely indicate it failed syntactic checks.
Are you suggesting that TLS clients will reject an otherwise-valid certificate chain which has a CCID that matches the TLS client's desired use of the certificate, because the log indicated it failed syntactic checks?

It's not a bad thing, it does place additional burden on logs though. Monitors will have to verify the log's honest behaviour on this aspect as well.

The other question is - aren't certificate classes different enough to merit running different logs, where the log's identity (or some other metadata) indicates which CCID it's good for?
I'm a bit weary of specifying a behaviour for the general case where I don't have concrete examples for more than one particular case.

On Tue, Oct 28, 2014 at 2:09 AM, Santosh Chokhani <[email-masked]<mailto:[email-masked]>> wrote:
Relying parties relying on the checks made by log server may be problematic if both do not have the same trust store if the initialization variables are different.

From: Trans [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rick Andrews
Sent: Monday, October 27, 2014 6:33 PM
To: Russ Housley; Steve Kent

Russ, comments inline.

-Rick

Steve and Rick:

[Rick] In most cases, yes. If someone has access to the server configured with that certificate, they can do a TLS handshake and get the chain in nearly all cases. We see some web servers that are missing the intermediate CA cert, and some browsers (IE, for example) will follow the AIA extension (if it’s in the cert) and fetch the intermediate. Any client can do that too. But if the CA didn’t put an AIA extension in the cert and you can’t find a server with that cert, it might not be possible to find the intermediate CA cert. And without the intermediate (or intermediates!) the log won’t accept it.

Alternatively, a log could check to see if the reported certificate is already present, and if so, return the older entry to the party that reports the certificate.  I seem to recall reading this idea at some point, buy I admit I did not look into the current I-D to see if that was where i read it.
[Rick] RFC 6962 and bis-04 say “If the log has previously seen the certificate, it MAY return the same SCT as it returned before.” But this would have to be expanded to say “If the log has previously seen the certificate and CCID, it MAY return the same SCT as it returned before.” It’s a bit more complex, since the log server may not support the CCID or any checking, in which cases it would always log the entry with CCID =1 that indicates “This log does not perform syntax checks”, or CCID=2 that indicates “This log does not support syntax checks for the asserted CCID”.

Value Interpretation

If the log performs some validation checks, are you suggesting that a relying party can leverage the work already done by the log?  If so, it puts the log checking at a different place in the certificate validation than I was imagining.
[Rick] Yes, a relying party could leverage the work already done by the log server, if the RP trusted it. Google would probably advise against this, since they have been pretty consistent in saying that CT doesn’t require you to trust anyone including the log server.

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 28 Oct 2014 19:27:52 +0000

Eran,

See in-line below.

From: Eran Messeri [mailto:[email-masked]]
Sent: Tuesday, October 28, 2014 12:46 PM
To: Santosh Chokhani
Cc: Rick Andrews; Russ Housley; Steve Kent; [email-masked]
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

Overall the mechanism described seems reasonable. Can you help me understand the benefits from the TLS client's perspective?
[Santosh] The primary benefit would have come if the log had enforced and not registered a mal-formed certificate.  Log acceptance of certificate seems to what the WG prefers.  In that case, benefits to the client are reduced.

IIUC, the log will never refuse to include a certificate, it will merely indicate it failed syntactic checks.
Are you suggesting that TLS clients will reject an otherwise-valid certificate chain which has a CCID that matches the TLS client's desired use of the certificate, because the log indicated it failed syntactic checks?
[Santosh] That could be one thing.  What I was saying in the thread is that even if the Log said that the certificate passed the checks, client must do its own path validation unless the client and log are using the same chain and same 5280 path validation initialization variables.

One advantage of logs doing checking and rejecting the certificates is that the human user will not go through the error-prone decision making about the security ramification of failed path validation.

The other question is - aren't certificate classes different enough to merit running different logs, where the log's identity (or some other metadata) indicates which CCID it's good for?
I'm a bit weary of specifying a behaviour for the general case where I don't have concrete examples for more than one particular case.
[Santosh] To my knowledge, lot of path checks are the same.  Different classes of certificates may warrant checking KU, EKU and extracting and matching names from different fields (say Subject DN or SAN).

Russ, comments inline.

-Rick

Steve and Rick:

Value Interpretation

---

From: Eran Messeri <[email-masked]>
Date: Wed, 29 Oct 2014 11:32:12 +0000

In that case, how about including the CCID and the results of the checks
the log performed in the get-sth response, but not in the SCT itself?

The log could still sign the complete get-sth reply so submitters get a
confirmation it is indeed the log which performed the checks, and TLS
clients will not be burdened with handling another field in the SCT there's
no immediate use for.

As I said, I see the value in getting an "independent opinion" on the
validity of a chain submitted to the log (both in syntactic and semantic
compliance perspectives) and is much more useful than the current error
handling approach (where the log returns a vague error). I just like to
exclude this information from being embedded in the SCT if it's not useful
for TLS clients.

On Tue, Oct 28, 2014 at 7:27 PM, Santosh Chokhani <[email-masked]>
wrote:

>  Eran,
>
>
>
> See in-line below.
>
>
>
> *From:* Eran Messeri [mailto:[email-masked]]
> *Sent:* Tuesday, October 28, 2014 12:46 PM
> *To:* Santosh Chokhani
> *Cc:* Rick Andrews; Russ Housley; Steve Kent; [email-masked]
> *[Santosh] The primary benefit would have come if the log had enforced and
> not registered a mal-formed certificate.  Log acceptance of certificate
> seems to what the WG prefers.  In that case, benefits to the client are
> reduced.  *
>
>
>
> *[Santosh] That could be one thing.  What I was saying in the thread is
> that even if the Log said that the certificate passed the checks, client
> must do its own path validation unless the client and log are using the
> same chain and same 5280 path validation initialization variables.*
>
>
>
> *One advantage of logs doing checking and rejecting the certificates is
> that the human user will not go through the error-prone decision making
> about the security ramification of failed path validation.*
>
>
>
> *[Santosh] To my knowledge, lot of path checks are the same.  Different
> classes of certificates may warrant checking KU, EKU and extracting and
> matching names from different fields (say Subject DN or SAN).*
>
>
>

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 29 Oct 2014 20:21:10 +0000

Some of the other usages of the log checks are that subjects and CAs can also see this and take corrective actions.

Also, I am not saying relying parties do not use the checks made by the logs. it is just that the relying parties may need to perform their own checks also due to differences in logs perception of path validation state and relying party’s.

From: Eran Messeri [mailto:[email-masked]]
Sent: Wednesday, October 29, 2014 7:32 AM
To: Santosh Chokhani
Cc: Rick Andrews; Russ Housley; Steve Kent; [email-masked]
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

In that case, how about including the CCID and the results of the checks the log performed in the get-sth response, but not in the SCT itself?

The log could still sign the complete get-sth reply so submitters get a confirmation it is indeed the log which performed the checks, and TLS clients will not be burdened with handling another field in the SCT there's no immediate use for.

As I said, I see the value in getting an "independent opinion" on the validity of a chain submitted to the log (both in syntactic and semantic compliance perspectives) and is much more useful than the current error handling approach (where the log returns a vague error). I just like to exclude this information from being embedded in the SCT if it's not useful for TLS clients.

On Tue, Oct 28, 2014 at 7:27 PM, Santosh Chokhani <[email-masked]<mailto:[email-masked]>> wrote:
Eran,

See in-line below.

From: Eran Messeri [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, October 28, 2014 12:46 PM
To: Santosh Chokhani
Cc: Rick Andrews; Russ Housley; Steve Kent; [email-masked]<mailto:[email-masked]>
Subject: Re: [Trans] Goals and generic mis-issuance fgramework

Russ, comments inline.

-Rick

Steve and Rick:

Value Interpretation