[stir] Re: Comments on draft-wendt-stir-certificate-transparency-03

[Chris Wendt <[e-mail]>]

Our intent is not to be experimental, and based on feedback from IETF 119, we specifically moved away from too much alignment with RFC9162 other than to use CT as a concept and a general framework as is happening in other working groups as well.  But definitely want feedback on these points.

-Chris

> On Jul 21, 2024, at 6:55 AM, Jonathan Rosenberg <[e-mail]> wrote:
> 
> Oh - and the other big issue is that RFC9162 is experimental. Is the STIR transparency doc also meant to be experimental? 
> 
> Thx,
> Jonathan R.
> 
> 
> On Sun, Jul 21, 2024 at 12:53 PM Jonathan Rosenberg <[e-mail] <mailto:[e-mail]>> wrote:
>> Apologies if I am raising issues already discussed and I have missed it:
>> 
>> The main problem this draft is trying to solve, is to detect cases where two CAs both issue certificates for the same TN. However, there are two cases where this might happen - accidential or malicious. I can see this draft working well in the accidental cases. But in the malicious case, this seems much harder. The malicious provider could elect to not log the issuance of the certificate. The draft tries to solve this (I think) by basically REQUIRING that all passports contain a reference to the log in which the certificate was issued. A malicious provider would therefore be caught when a verifying party insists on the presence of the log, and if not present, considers the passport invalid. Perhaps this is why the document states that inclusion of the SCT claims is at MUST strength.
>> 
>> THe problem is - this approach is essentially not backwards compatible with existing STIR deployments. COnsider the first VS to look for SCTs and require them in passports. That VS would immediately reject (or perhaps accept but take offline actions), any passport omitting them, which means all AS would need to be including this before the first VS goes live. In other words - there is no way to do an incremental rollout across AS, if the goal is to detect malicious CAs.
>> 
>> If the scope is truly limited to accidental cases, then inclusion of the CST should be a SHOULD and not MUST.
>> 
>> In either case, I think the document needs a discussion of the threat model it is trying to address, and also describes how incremental deployment would happen.
>> 
>> Thx,
>> Jonathan R.
>> 
>> 
>> --
>> Jonathan Rosenberg, Ph.D.
>> [e-mail] <mailto:[e-mail]>
>> http://www.jdrosen.net <http://www.jdrosen.net/>_______________________________________________
> stir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]