On 12/09/14 20:26, Erwann Abalea wrote:
Nice idea, solves the RFC5280 concerns, and doesn't require a completely
new data structure.
IIUC, what you propose is that the PreCert is a CMS (RFC5652) with a
signedData content-type, for which the data is the TBSCertificate
(name-redacted or not, no necessary poison extension). The SignerInfo
refers to the PreCert issuer (CA or dedicated issuer, same as now).
It can only work if the log signs the content (=TBSCertificate) and not
the whole CMS, thus ignoring the PreCert issuer signature. Leaving that
signature aside isn't more risky than it is now because it's already the
case (the log removes the poison extension before signing the resulting
certificate, right?).
Yes. The log removes the poison extension, and (if a Precertificate
Signing Certificate was used) it also changes the issuer name and AKI to
match those of the final certificate's issuing CA. This behaviour can
remain the same.
I agree that using CMS to sign the Precert TBSCertificate is a good
solution to the duplicated certificate serial number problem. :-)
If the log signs the whole CMS, the SCT covers information unknown to
the browser at connection time (content of SignerInfo, maybe additional
attributes --authenticated or not--, digest algorithm chosen by the
PreCert issuer, etc).
2014-09-12 20:44 GMT+02:00 Jeremy Rowley <[email protected]
<mailto:[email protected]>>:
Why not use a TBSCertificate from RFC 5280 with no modifications
from the final certificate (no poison extension) and sign it with a
PKCS7 signature instead of a RFC 5280 signature? By doing this you
are not creating a valid certificate so you are not technically
breaking RFC 5280 (re-using serial numbers) and it couldn't be used
as a certificate even if some software incorrectly ignored the
poison extension.
Jeremy
-----Original Message-----
From: Trans [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Stephen Kent
Sent: Thursday, September 11, 2014 12:15 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: [Trans] Precertificate format
Ben,
> ...
> I managed to miss that proposal. I've found it now.
>
> There seems to be a flaw: if I'm an evil CA wishing to issue an evil
> certificate, I simply log a precert, minus serial, get an SCT*, log a
> certificate containing that SCT*, which I then revoke when requested
> to do so,
>
> In order to attack a user with the evil certificate, I simply issue a
> second copy with a different serial, containing the original
SCT*, and
> the certificate works. Yes, the discrepancy should be discovered in
> audit, but that is a significantly weaker protection than we get if
> the serial is included in the pre-certificate.
I agree that the attack you describe would work, but it needs to be
evaluated in the overall context of how CT works in the case of
several different types of attack scenarios. The threat model and
attack model text I just submitted provides a first cut at
describing such scenarios. Once we get agreement on that model,
let's revisit the question of whether the vulnerability you noted
above is significant relative to other residual vulnerabilities.
> Also this adds quite a lot of complexity in order to allow what
> appears to be, so far, an entirely theoretical use case.
I do know that when VeriSign used the Safekeyper HSM to issue all of
its certs (which it did for several years), it would have been
impossible to generate a pre-cert and matching final cert. So, the
concern I raise would have been a show stopper for them in that time
frame. I guess it depends on how one defines a "theoretical use
case" :-)
Separately, the pre-cert model, requires a CA to issue two certs
with the same serial number, which is a bad security practice. I
think it makes sense to re-consider forcing CAs to behave this way.
Steve
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
_______________________________________________
Trans mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/trans
--
Erwann.
_______________________________________________
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
