RE: nextUpdate

["Friedrichs, Paul (Contractor)" <FriedriP@ncr.disa.mil>]

Hi Sharon,

> -----Original Message-----
> From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]
> Sent: Monday, March 01, 2004 12:17 PM
> To: 'FriedriP@ncr.disa.mil'; Multiple recipients of list
> Subject: RE: nextUpdate
> 
> 
> Hi Paul,
> 
> I obviously wasn't clear in my earlier message. The standards are not
> claiming to be a higher authority at all. The standards 
> define a process for
> path validation with a standard set of inputs and outputs.

I want to understand whether (my) interpretation of IETF or ITU standards
are in question. Are we now referring (only) to a NIST standard? 

> The process
> produces a failure with an error code in the example you 
> cite. 

Can you be more specific? Which standard? What is the error code? What
information is passed?

> This does not
> mean that the certificate can't be used. 

The test criteria say the product must "reject" the certificate. This seems
to preclude use. Or, at least, certain testers might interpret this to
preclude use.

> It means the process 
> could not
> determine the revocation status of the certificate and therefore that
> process failed. The decision on whether or not to use that 
> certificate one
> that takes the results of path validation as an input, along 
> with other
> inputs. That process is not covered by these standards. 

I interpret this to mean that a compliant path validation component within a
commercial product could "fail" and generate error codes regardless of
whether the rest of the product paid any attention to either. Does the
standard require that the error message be consumed? If that's outside the
scope, then how can the scope include the case where there is no exposed
interface between the path validation component and, e.g., authentication
protocol logic within a single commercial product?

If products without such exposed interfaces are unable to become compliant,
would that mean that the standard is only required for standalone path
processing components?

> If path validation did not fail in the example you cite, 
> relying parties
> would have no way to know that current revocation status had not been
> checked. 

I disagree. "Failure" is one possible means of passing this information to
the business logic. It is not the only possible way. Failure is a means, not
an end. I also disagree that the only possible design is that the process
fails if it performs correctly and successfully determines that the
available status information is X hours older than the latest information.
The software didn't fail. It did what it's supposed to do. And it gave the
necessary information to the business logic. That's not component process
failure.

Plus, unless the error codes provide sufficient information to the business
application (as I described toward the end of my initial message), failure
may not be desirable for the relying party. How is the relying party to know
the specific details potentially useful for the necessary business decision?
Must it now use a non-compliant path validation component in order to
determine how out-of-date the revocation status information is?

Have we imposed the words/concepts "reject" and "fail" on what might be a
subcomponent - what might be an internal function - of relying party
software? What if other internal implementations achieve the same desired
result?

> The same holds true for all other reasons that the 
> process fails. 

Is it all or nothing? Fail or succeed? Nothing to support relying party
decisions? Earlier you said the relying party decision "takes the results of
path validation as an input." If it's just "fail," that's only telling the
relying party that she can have authentication or availability. The
authentication process should give (not drop) information useful in
supporting the estimation of authentication risk. Without this, PKI *does*
just "fail." We would be choosing to be more unreliable that we should be:
all-or-nothing authentication, authentication or failure. That's not robust.
It's unreliable, brittle. This is where I'm trying to help.

> Hope this clarifies what I was trying to convey.

Not yet. Please bear with me.

Thanks,

V/R Paul