Re: [Trans] Misissuance vs auditing/monitoring

[Stephen Kent <[e-mail]>]

Paul,

> It seems the discussion about misissuance is going into far too
> many different policy decisions favoured by different people. That
> makes it obvious that it does not belong in the base specification
> document.
I agree that the specs for syntactic and semantic mis-issuance should be
in a separate document, to better accommodate other types of certs beyond
the Web PKI, evne though they are out of scope for the current doc, as 
per the
TRANS charter, which specifies the scope of the first RFC:

    *Publish an update to RFC 6962 as a standards-track mechanism to*
    *apply verifiable logs to HTTP over TLS. *

*
* I do not agree that 6962-bis duck the question of what constitutes 
mis-issuance.
I believe its possible to define the term in a way that will accommodate 
other
cert types (even though that is NOT required for 6962-bis), and to 
include pointers
to an RFC that describes how CAs, Subjects, logs, Monitors and clients 
can know
what they're getting wrt mis-issuance checking.

One RFC will describe syntactic and semantic requirements, derived from 
CABF specs,
omitting parts that cannot be checked without Subject or CA-specific 
info. That seems
to be the appropriate set of checks for the Web PKI.

> The goal is to provide a distributed logging infrastructure that people
> can use with their clients and monitors. Consumers and providers can
> pick those that match their operational expectations and policies.
This characterization omits mention of the context that is used to justify
CT, i.e., the Web PKI. The charter later says:**
*
*

    *As DANE (RFC6698) provides an alternative keying infrastructure to
    that used *
    *in the current web PKI, the working group should consider
    appropriate client *
    *behavior in the presence of both DANE-based keying and current web
    PKI when*
    *standardising CT.*


The charter also says that the WG could be re-chartered to address certs 
used with
other security protocols. The approach I'm describing will accommodate 
certs used
in other contexts, so if we pursue logs for DANE in the future, it will 
still work.
> Logs will have different policies on which kind of certificates they will
> accept into the log or not. But we should not come up with policies for
> people running the logs in different commercial or legal systems. Each
> will develop their own rules.
I find these statements a bit confusing. First, under the current 
charter we're talking
about just one type of cert, an X.509 cert issued to a web serer, right? 
We're
not talking about code signing certs, certs for e-mail, certs for IPsec, 
etc. Those
can come later, if the WG is re-chartered and elects to pursue them.

My proposal for syntactic checking can accommodate certs issued for 
other purposes, easily.
All we need to do is establish an IANA registry that specifies the type 
of cert that
is being logged, as asserted by a CA or Subject. For each cert type 
there will be
a matching RFC that defines what checks are to be performed. (Each new 
version of
a cert spec receives a new registry entry, so that one knows which 
version is being
asserted. Thus the scheme can accommodate new CABF guideline versions, etc.)

The registry also should include a set of responses for a log to assert 
relative to the
cert type asserted by the CA or Subject. For example, "I don't do 
checks", "I don't
check this cert type/version", "I checked it and it passed" and "I 
checked it and it
failed" or "the submitted said no criteria exists, so I didn't check."

A log, if it _elects_ to perform checks, will know which checks to 
perform based on the
value asserted in the log request. A Monitor that performs checks can 
make use of this info,
because it will be part of the log entry. A Client that wants to accept 
SCTs from a log
based on its ability (and willingness) to perform checks van learn what 
is and is not
checked by the logs that generated the SCTs that the client encounters.

This is a powerful mechanism for CT. One does need separate RFCs to 
define each set of
checks, but the log interface and SCT format have to accommodate 
expressing the CA/Subject
and log assertions if this capability is to be enabled. Thus the base 
doc needs to
include such specifications.

For the Web PKI context, the policies that exist are ones defined by the 
CABF,
as profiles of RFC 5280 and RFC 3279. These policies apply to ALL CAs 
issuing EV certs,
by definition, across all jurisdictions, AFAIK. I am not aware of any 
legal system
differences that have arisen at the level of the specification that we 
are discussing.
CABF members include CAs from North American, Europe, and Asia, and 
several of these
CAs offer services in other parts of the world, e.g., Africa, via local 
RAs.
Do you have some examples of the differences that are of concern, at the 
level of
specification that we're discussing?

More to the point, recall that my revised proposal does not _require_ a 
log to perform
any syntactic checks; it _allows_ a log to do so, and to advertise the 
result of what it
did, which provides for grater "transparency" wrt log operation.
> The focus should be on what the minimum requirements are for inclusion
> into the log in such a way that the log is able to fulfill its function.
Again, if you have read my _revised_ proposal, the syntactic checks do 
not preclude
inclusion of ANY cert into a log. Syntactic checking by a log is an optional
service. I believe that Monitors ought to be required to perform syntactic
checks, as well as semantic checks, so that clients know what services they
get from Monitors, in a uniform, easy to understand fashion. But, that is a
separate debate, right?
> Being resistant to spam/dos attacks is an important factor. But should we
> just mention it in the security sections and leave it open for 
> everyone to
> decide on? Someone might want _only_ self signed certificates in their 
> log
> server and it would be wrong if the base specification would forbid that.
Two comments here:
- 6962-bis mandates path checking (not well specified) to address one form
of dos attack against logs.
- you mention self-signed certs, but they (and DANE "certs") are explicitly
excluded by 6962 and 7962-bis, based on the anti-dos mechanism noted above.
So, your two observations above seem to be in conflict. Are you 
suggesting a
change of scope in that respect? Is your comment here a direction issued as
WG co-chair to the document editors?
> The serial number seems to be a hard requirement, as it is needed to
> uniquely identify the certificate. CABF policy is not. I'm sure there
> will be logs that will only allow EV certs. That's fine. Those policies
> do not belong in our document.
I presume your comment about serial numbers is saying that a log entry 
needs to
include a cert serial number, but that checking syntax (beyond the path 
validation
requirement), is not essential to the function of a log. I agree.

But, enabling a log to perform this function, by requiring the log 
interface and
log entry and SCT formats to accommodate a simple assertion about cert type,
and whether a log elected to perform syntax checks, does seem very valuable.
This is especially true if one wants to expand logs to accommodate other 
forms
of certs in the future, as you suggested above.

Also, to be precise, my proposed does not impose a requirement that a 
cert be
evaluated against DV or EV requirements, by a log. A CA or Subject can 
submit
a (pre-) cert and assert that it does NOT purport to comply with any 
criteria.
Using the IANA registry model I described above, other cert types can be
accommodated cleanly, and need I say, _transparently_, while making it 
easy for
Monitors and clients to know what type of cert has been logged.

> For the base document, we need to focus only on the requirements needed
> for self-preservation of the log.
A log is one element of CT. We also need to describe the security functions
of Monitors, clients, and Auditors (if this last one survives). I also 
think we
need to include an attack analysis.
> If someone is interested in writing a separate policy document for a
> specific type of log, that would be great. For instance a log that only
> takes in CABF members issued certificates.
I don't think you meant exactly what you said; a non-CABF member might 
assert
that they issue DV or EV certs.

In summary, what I propose is that 6962-bis be revised to:

- include an attack analysis

- accommodate an assertion by a CA or Subject about a cert submitted to 
a log
in the log submission, log entry, and SCT formats

- accommodate an assertion by a log of what checks it performed, if any, and
what was the outcome, in the log entry and SCT formats

- refer to a separate RFC that creates the IANA registry for these 
assertions,
and establishes the range of log assertions

Yet another RFC will define CA/Subject assertions values for DV and EV 
certs,
and the associated syntactic and semantic checks for these types of Web 
PKI certs.
Since the focus of the initial doc being produced by TRANS is Web PKI 
certs, I think
it is appropriate to cite this last RFC as consistent with that focus.

Steve