On 08/11/17 00:54, Eran Messeri wrote:
One way for a single SCT to be valid for multiple certificates is to
omit the fields that change from the data covered by the SCT's signature.
For short-lived certificates this would (likely) be the serial number,
notBefore and notAfter dates.
This means there's no need to re-request an SCT each time a new
short-lived certificate is minted, and the SCT covers all key fields in
the certificate's TBSCertificate structure (Subject Alternative Names,
key, etc).
> The drawback is that without a serial number
Hi Eran. Just thinking about the problem space here...
(1) it is not possible to
verify CAs don't violate the unique serial number requirement
(effectively reducing auditing capabilities)
One way to mitigate this would be to require the use of a deterministic
serial number scheme (i.e., where the serial number is calculated from
the rest of the TBSCertificate just before the cert is signed).
(2) mis-issued certificates can't be revoked using the usual means.
The "usual means" of revocation (CRL and OCSP) "don't work" anyway.
That is, many of today's TLS clients no longer use these mechanisms.
Alternative revocation mechanisms could be invented that revoke groups
of certs (e.g., perhaps by SHA-256(SubjectPublicKeyInfo), or by
SHA-256(SharedSCT), etc, instead of by serial number).
Note that such a mechanism cannot be implemented either using 6962 or
6962-bis: Both documents mandate that the SCT covers all fields in the
TBSCertificate (at least). But, if the design was changed to exclude
some fields, it seems to me that this solution would otherwise be
compatible with the rest of the CT protocol.
How about defining an SCT extension that, when present, indicates that
the SCT's signature doesn't cover serial number, notBefore and notAfter?
On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore <[email protected]
<mailto:[email protected]>> wrote:
The question of how to log short-lived certificates is something
that's been coming up more frequently recently, and it's
independent (mostly) of the issuance mechanism. I think we've
got time to discuss it during the session at IETF 100, and
it would be helpful if there's a specific proposal to use as
a starting point. Will the folks working on this be
at the meeting?
Melinda
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
<https://www.ietf.org/mailman/listinfo/trans>
_______________________________________________
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
