Re: [Sidrops] 6486bis: Failed Fetches

[Jay Borkenhagen <[e-mail]>]

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.



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

Thank you.

						Jay B.