RE: nextUpdate

[Sharon Boeyen <sharon.boeyen@entrust.com>]

RFC 3280 is a profile of the X.509 base standard. In section 6.1.3 the
revocation check is included in path validation through step 3 of subsection
(a). In the penultimate paragraph of 6.1.3 RFC 3280 indicates that if any of
steps (a), ... Fails, the procedure terminates, returning a failure
indication and an appropriate reason. RFC 3280 does not specify what the
reason or error message is or what action a relying party needs to take upon
receiving an error message. That part is not standardized in either 3280 or
X.509. You can probably find statements in both specifications that say the
certificate should not be trusted or should not be used if path validation
fails, but there are some legitimate business reasons, such as the one you
stated, that lead to situations where certificates are used by relying
parties even though path validation failed. There can be situations where
the relying party might take one action for one error (e.g. if working
offline and unable to obtain current revocation status info - use the
certificate) and others where the relying party might take the opposite
action (e.g. receiving an error stating that path validation failed because
the certificate had been revoked.).

There are no standards that I'm aware of that dictate particular error codes
or relying party actions on specific error conditions. The only standards I
was referring to was X.509 and RFC 3280. 

The PKITS test suite tests relying party path validation logic and
therefore, in conformance to the standards that process rejects certificates
and returns a reason for the failure. In most cases, that will likely result
in the certificate not being used, but in some cases, such as the one you
raised that may not necessarily be the case. However, even in those cases
path validation did fail.

I think I better leave it to the NIST folks to represent the PKITS test
suite itself - I was only attempting to clarify what the standards do and do
not cover.

Cheers,
Sharon
-----Original Message-----
From: Friedrichs, Paul (Contractor) [mailto:FriedriP@ncr.disa.mil] 
Sent: Monday, March 01, 2004 1:30 PM
To: 'Sharon Boeyen'; Multiple recipients of list
Subject: RE: nextUpdate


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