Eran,
I see two issues:
* What should the precertificate contain.
* What should be the format of the precertificate.
First I'd like to point out that there already is a way to issue
precertificates without violating section 4.1.2.2 in 5280:
As Matt correctly pointed out, when a Precertificate is signed by a
Precertificate Signing Certificate, then the log produces a signature
over a TBSCertificate that _uses the final issuer's identity_, not the
one in the Precertificate Signing Certificate (hence the requirement
that the Precertificate Signing Certificate will be signed directly by
the certificate that will ultimately sign the end-entity certificate
the Precertificate represents).
Well, since certs are NOT used to sign anything, I can't agree with the
phrase "As Matt correctly pointed out" ;-).
That is explained in section 3.2 of RFC6962 ("Structure of the Signed
Certificate Timestamp") or in compliant code
<https://github.com/google/certificate-transparency/blob/master/java/src/org/certificatetransparency/ctlog/LogSignatureVerifier.java#L149>.
We could do a better job of explaining this in RFC6962-bis (I
personally found it confusing when implementing the Java CT API).
6962-bis is what needs to be clear. Also, code is not generally viewed
as a spec, for IETF purposes.
On what precertificates should contain:
Seems like there's a consensus that it should be all data in the final
certificate, except for the serial number, for which there's no agreement.
The argument against including the serial number, raised
Count me as not part of the consensus. I still want to see an analysis
of why selected
cert data needs to be part of the SCT.
mostly by Stephen, is that it may be difficult for CAs who use HSMs to
determine/generate the serial number in advance. I don't recall any CA
strongly supporting this position (and, given precertificates from
several CAs have already hit CT Logs, that's definitely not an issue
for several CAs).
On this list, very few CAs seem to be participating. I seem to recall
one CA commenting that
they had concerns about the per-cert model. I see that one CA, a
co-author of the doc, says
it was easy to implement. When I was in Beijing last week I spoke with
folks who deal
with cert issuance there (under CNNIC) and they were completely unaware
of the TRANS WG.
I wonder how many other CAs outside of the CABF are tracking this activity?
The argument for including the serial number is its necessity for
revoking a certificate - Somebody has mentioned alternative revocation
mechanisms that do not require it but have not provided any
references, and all current mechanisms I know of require the serial
number.
We all realize the requirement for pre-generating the serial number is
a disruptive one for the certificate issuance process - Given the
authors of RFC6962 have tried hard not to introduce disruptive
changes, I think this is a reasonable given the necessity of the
serial number.
here's an off-the-cuff idea on how to have our cake and eat it too.
1. A CA submits a cert template ala CRMF.
2. A log operator generates an SCT* based on this data, and returns it.
3. The SCT* is embedded in a cert by the CA.
4. The CA submits the SCT*, plus the issued cert plus to the same log
operator, and
a new data item is created, the SCT. It links the serial number to the
previously-issued
SCT*. If there is a mismatch between the SCT* and the final cert, the
Monitor will
refuse to issue an SCT.
(A Subject who submits its cert gets an SCT. The serial number is not a
problem here.)
A TLS client that checks for the presence of an SCT acts as before, but
with slightly
different processing to match the SCT against the received cert. This
seems to offer
equivalent (analogous) guarantees to the client, but without a threat
model I can't be
sure if there is a gap here.
A Monitor will examine a log to determine when an SCT* was issued and no
SCT was issued subsequently. That is a red flag. An SCT without a
preceding SCT* is not a problem, as this
is what would occur if a Subject (or OCPS server?) requested an SCT.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
