Re: [stir] Review of: draft-ietf-stir-passport-05

[Dave Crocker <[e-mail]>]

Eric,

Thanks for the quick response.


On 7/29/2016 6:57 AM, Eric Burger wrote:>

> Dave - Thanks for the review. I agree with a lot of your meta points,
> most especially that a major revision during last call that makes
> some not insubstantial syntactic changes is unusual, to say the

FWIW there also were not insubstantial semantic changes, by my reading.


> Another thing that perhaps we need to put into the document suite
> relates to your comment about certificate management. In a normal,
> interoperable protocol one would have a single certificate management
> mechanism that everybody agrees to. The problem is the approach used
> for certificate management in the case of STIR/PASSporT is directly
> an embodiment of policy. Because the target audience for the protocol
> is (today) highly regulated with differing national policies and
> policy bodies, it is just not possible to mandate a particular
> certificate policy (i.e., your comment about key rollover and one I
> think you obliquely touched upon, what is the Subject of the key
> doing the signing).

You appear to be saying that the actual use of this for SIP is going to 
vary according to a wide variety of policies.

If this means a variety of independent services, that's fine, of course. 
  If this means a variety of services that are supposed to interoperate, 
it's not.

So forgive me, but how does that provide the end-to-end authentication 
service that is the primary goal of this working group and that will be 
credible?


> The WG is producing a straw proposal that would
> provide some semblance of a baseline, but it is not clear there will
> be more than one or two implementations of that policy.

cf, preceding question.


> All this said, I will also defend the document in that (admittedly
> with assistance from me and Chris Wendt) an undergraduate student
> coded a STIR authentication service and STIR validation service in
> under a year,

I've no doubt that someone could take this specification and produce 
code based on their reading of it.  People do that with incomplete 
specifications all the time.

The question is how much they had to fill in gaps and whether the next 
reader would fill in the same gaps in the same way and produce an 
interoperable implementation?

By my reading, that's a very low probability outcome...


d/

ps. (Just in case I missed text from you:  I don't see any comments from 
you in the remainder of your message.  Only a copy of the message I sent.)


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net