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