Re: [Sidrops] 6486bis: Failed Fetches

[Stephen Kent <[e-mail]>]

Jay,
> Steve,
>
> I would like to comment on two things you recently wrote to this list:
>
> Stephen Kent writes:
>   > When I the WG chairs tell me that I misunderstood the WG consensus re:
>   > strict correctness then I will revisit this topic. However, the recent
>   > messages from Mikael and Job suggest that your perception of WG
>   > consensus is not accurate. This issue is one that needs to be decided by
>   > network operators, not by developers of RP software. I agree with the
>   > observations made by Mikael and Job, i.e., that requiring strict
>   > conformance with manifest rules is the preferred approach.
>
> I don't think viewing this as "network operators" vs "developers of RP
> software" is a productive approach.
>
> I am a professional network operator -- somebody pays me to do that.
> I also happen to have some opinions on how a successful PKI should
> operate, but so far no one has offered to pay me for those opinions.
> If asked to use only the network operator part of my brain to say
> whether strict conformance is the best approach here, I would answer
> "Honestly, I don't care.  As a network operator I care only that the
> VRPs I use in my network are as trustable and reliable as possible."
> I certainly have opinions how _how_ to make the system as trustable
> and reliable as possible, but I know others have thought about such
> aspects far more than I have -- in particular folks who have
> implemented RP software.
>
> At the risk of making my comments here too personal (they are not
> intended that way), my friend Job wears both of these hats: he is a
> network operator, and he is involved in developing an RP
> implementation.  That's great!  I value his opinions, and I am happy
> to hear that you do, too.  But it would be fruitless to attempt to
> determine which parts of Job's psyche most inform his opinions voiced
> in this WG.  So rather than attempting to do so, I would like to ask
> you to also value the opinions and contributions of other RP
> implementors, particularly those who have been active in this
> discussion.  Many network operators do not participate here in
> SIDROPS, but presumably all RP implementors do.
The crux of the issue is whether it is preferable to reject all objects 
at a pub point if an error is detected (until the error is rectified), 
and thus potentially treat many more routes as having an unknown 
verification status, or to accept bits and pieces of data from a pub 
point with the potential that some routes will be treated as valid, even 
if they are invalid. To me, that is a value judgement to be made by 
network operators, not by developers of RP software. Job can pick 
whatever hat fits him best.
> > >> You absolutely have to deal with this issue in 6486bis in its current
>   > >> strict form. Any introduction of a new object type will permanently
>   > >> break CAs that use these objects when validated with a relying party
>   > >> software that is not aware of this type. I don’t think this is
>   > >> acceptable, as it effectively blocks the introduction of new types
>   > >> pretty much forever.
>
>   > No, it does not. What I suggested is that when a new object is proposed,
>   > it is the responsibility of the those proposing the new object to
>   > explain how it will be incrementally deployed. That explanation belongs
>   > in the RFC defining the new object, and in an updated version of 6486
>   > will need to be generated. We have no good examples of new objects that
>   > provide a basis for describing how to accommodate incremental
>   > deployment, and thus no basis for defining such mechanisms at this time.
>   > It might be the case that a new object will be defined that requires the
>   > CA to maintain a separate pub point using some newly-defined SIA
>   > pointer, indicting that the new pub point contains the new object and
>   > thus RPs that don't know how to process the object MUST NOT follow that
>   > pointer. There will need to be agreement on how long a CA MUST maintain
>   > the old pub point, etc. But, absent a concrete example of a new object
>   > type that warrants this sort of effort it is premature to write a spec.
>
>
> The situation you describe here sounds horrible, trying to keep older
> RPs from seeing newer objects they're not equipped to fully
> understand.  A much more robust system would be one where RPs are not
> thrown off by unknown object types retrieved from known publication
> points and listed in manifests.  Clearly older RPs would not know what
> use to make of newer objects, and thus would ignore them.  Network
> operators interested in taking advantage of the new objects would
> first need to upgrade their RPs in order to do so, but that's BAU.

Experience with X.509 cert extensions suggests that the approach I noted 
is preferable. Saying that older RPs can ignore objects they don't 
understand introduces ambiguity in RP behavior, which is precisely the 
concern that motivated the effort to generate 6486bis.

Steve