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

Hi Steve

On Feb 11, 2014, at 7:12 PM, Stephen Kent <kent@bbn.com> wrote:

> Tim,
>> 
>>> --
>>> 
>>> presuming there is consensus to adopt, i have some some nits we can
>>> discuss when it is a wg item.
>>> 
>>>  o i thought folk wanted a blank line between the URI(s) and the key
>>> 
>> I am not sure that I care too much about this as long as it's well defined.
>> 
>> But if the format is open to change, then I would feel more for a key=value style, or dare I say even json.. this is parsed by the machines after all. And using something like json makes it much more flexible regarding ordering of elements, or extending should that ever be necessary.
> I'm not a fan of switching to JSON at this point.

I noticed I stand alone in the matter. No worries. Note the 'if' and let's move on..

>> 
>>>  o last para of 2.2 says
>>> 
>>>       Where the TAL contains two or more rsync URIs, then the same
>>>       self-signed CA certificate MUST be found at each referenced
>>>       location.
>>> 
>>>    maybe should say what happens when one or more do not have the same
>>>    cert?  does the whole TAL get ignored?
>> I agree, but on top of that having multiple publication points by definition implies that there will be differences, albeit short lived.
>> 
>> I would like to see wording along these lines.
>> = TA MUST increment serial number whenever they re-issue the CA cert
>> = TA SHOULD* publish the CA cert in all locations 'asap', within 1 hour?
>> = TA SHOULD* remove the cert from unmaintained locations
>>   *: They may not be able to if this is hosted at a third party
> I agree with Randy that the references to "TA" above should just be "CA"

Sure. I used to TA rather broadly here, including the CA operated by the Trust Anchor entity.

> 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..

>> To handle all this more elegantly I think there should be a mechanism for TAs to publish replacement TALs. To add, or remove URIs, or even to do planned key rolls (for example: TA wants change HSM vendor). What if the TA could optionally publish one (1) signed object containing an updated TAL? And possibly some dates: do-not-use-this-before, and do-not-use-other-after?
> These are desirable, additional features, but I agree with Randy that they merit a new work item.
> The change to allow a TAL to contain pointers to multiple locations for cert retrieval seems to
> be an easy change that we can agree upon.
>> This would allow RPs to use existing TALs to discover updates and process automatically (it is signed by the key that I trust). It could stop re-trying retired URIs, and start using the new ones. And even planned key rolls could be as simple as this on this level (provided the TA re-issues and publishes all the products before the change date, under the new key and in its own repositories).
> 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.

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.

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.

Tim

> 
> Steve
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr