Re: [sidr] working group adoption poll for draft-huston-sidr-rfc6490-bis

[Stephen Kent <[e-mail]>]

Tim,

>>> ...
>>>
>> I'm puzzled by the references to a "third party" above. Why would an entity acting as
>> a TA not want to control all of the locations where it's TAL identifies as places from
>> which to acquire the vert?
> Actually I think this could be a feature. Call me paranoid, but publishing the cert in places where even your own disgruntled operators can't reach it, and remove it or replace it with an old one, seems to me like an idea to entertain. Such access generally does not require any HSM, card quorum etc. But doing this of course introduces the risk of these third party points going rogue. Hence the "no control" remark. But see below..
I don't see the tradeoff as being a positive one, but at least I now 
understand the motivation for your statement.
>> ...
>> As I noted above, this seems like a good, new work item.
> Fair enough. I did not want to bring this up as a show stopper for going forward with the bis, but it seemed relevant to talk about this now.
sure.
> The rogue third party risk could be mitigated by signed TALs. A signed (presumably controlled by an HSM and N out of M cards) statement could remove such a publication point from the list. On top of this RPs could regularly re-check certificates in multiple locations to find the most recent. They could also cache the most recent one they have found and refuse older ones. This re-checking should not be needed every few minutes, but once every 24 hours or something seems quite reasonable to me.
a once per day retrieval seems quite reasonable to me too.
> But since I don't think it's feasible to get the signed TAL idea worked out for the bis, it's probably best for now to say that the entity acting as a TA should only publish the CA certificate in locations it has full control over. This would also make zealous re-checking by RPs less relevant at this stage.
agreed.

I'm happy to work with you on a new doc that explores added security 
functions for TALs.

Steve