On 02/07/15 15:00, Stephen Kent wrote:
Rob,
Hi Steve.
I agree with your conclusoon that inclusion of the issuer public key hash
will enable a browser to verify the correspondence between an SCT without
interacting with a log. Even though we don't yet have a browser behavior
spec, I agree that this is a good candidate behavior to enable.
Do you propose this as an extension to the current SCT format, or a change
to the format?
A change to the format. Proposal here:
https://github.com/google/certificate-transparency-rfcs/pull/58
If you propose a change, then I'll argue that my proposed
cert type declaration and checks performed fields also should be included,
since we'll be making a not backward compatible change to the SCT.
6962-bis has already made backwards-incompatible changes to RFC6962 SCT v1.
If this is an (optional) extension, then I guess my proposed fields can be
the second and third extensions defined.
I think that required fields should be in the main part of the SCT
structure, whilst optional fields should be extensions.
IINM, we agreed a while ago that your proposed fields (cert type
declaration and checks performed) would be, at most, optional.
(I still think that it makes more sense for monitors, not logs, to
perform checks relating to the declared cert type).
Steve
#80: Re-introduce the issuer key hash into the Precertificate
Comment (by [email protected]):
This problem affects browser clients and any other client that wants to
verify that an SCT corresponds to a particular cert. A browser has the
full cert chain (from the TLS handshake) and the corresponding SCTs,
but
it is _not_ expected to have the full log entries (i.e. extra_data,
etc).
In the current text, the SCT is bound to the Issuer Name (because
that's
in the TBSCertificate), but not to the Issuer Key (because that's
not in
the TBSCertificate).
There could exist two or more publicly-trusted intermediate CA certs
with
the same Name but different Keys. One of those intermediates might be
logged, while the other(s) are not logged. Each of them could issue
leaf
certs that have an identical TBSCertificate. Only one of those leaf
certs
needs to be logged for there to exist SCT(s) that are valid for all of
those leaf certs.
The logged leaf cert might get revoked, but the other(s) might not get
revoked. However, the SCT(s) would still work for all of those certs,
including the non-logged ones.
Therefore, we need to fix SCTs so that they're bound to the Issuer Key
Hash as well as the Issuer Name.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
