Subject: RE: On cross-certificates and pathLenConstraint

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Sep 2004 12:51:09 -0400

At 9:55 PM +0100 9/2/04, Stefan Santesson wrote:
>Steve,
>
>I've learned that in discussions like this you have to make small steps
>and agree on the fundamental basics before you can dig into details.
>
>So I just try to establish the simple truth that RP's have the right to
>deny trust in any certificate for any reason. And I mean literally ANY
>reason. No exception what so ever.

First, the term "trust" is one I try to avoid, so we're off to a bad 
start. If what you mean to say is that an RP can choose to reject any 
cert for arbitrary reasons, I agree. We're talking about a person, 
and people make value judgements for arbitrary reasons, so this makes 
sense.  Unfortunately, people can't perform cert path validation 
without the assistance of software. One of our jobs as standards 
developers is to provide a uniform means of performing path 
validation so that users can configure the process to get predictable 
results irrespective of the vendor of the path processing software. A 
problem arises when we try to satisfy the notion of rejecting certs 
for arbitrary reasons and the notion of automated path processing, 
presumably with a reasonable level of user control.

What I hear you saying above is that a vendor is free to "augment" 
path processing to enable a user to cause the algorithm to reject any 
cert for any reason. That seems very broad, and probably not viable. 
After all, "any reason"  is so vague that it seems unlikely that we 
can provide an algorithm or an API that will accommodate it. Instead, 
what I sense is a desire to justify a vendor's parochial choice of 
what ways a user can specify some (not any) reasons for rejecting a 
cert, and that conflicts with the standards motivation I cited above.

So, I am not sure that we agree on the basics, given the way you have 
described them.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 03 Sep 2004 14:45:17 -0700

Stephen Kent wrote:

> start. 

I guess that's why you always use "TA" rather than "Trust Anchor" ;-)

> If what you mean to say is that an RP can choose to reject any 
> cert for arbitrary reasons, I agree. 

This paragraph motivates me to reply. An RP is obviously authoritative
for the sources of information that that relying party trusts.

Now, do RP reasons really matter for PKIX standard developers? No.
An RP should be able to reject any cert and is 100% authoritative do
so. Period. An RP can also decide to just _use_ the cert, without
any desire to rely (as an RP) on any representations by the cert's
issuer.

Different RPs will say different things. And this is fine, because
PKIX cannot tell RPs what to say, trust or even what to believe.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Sep 2004 12:59:20 -0400

At 2:45 PM -0700 9/3/04, Ed Gerck wrote:
>>First, the term "trust" is one I try to avoid, so we're off to a bad start.
>

exactly!

>If what you mean to say is that an RP can choose to reject any cert 
>for arbitrary reasons, I agree.

good.

>for the sources of information that that relying party trusts.

agreed, when we talk about people. But, we create standards for 
algorithmic execution, and it may be unrealistic to expect software 
implementing these standards to be able to accommodate any arbitrary 
reason for rejecting a cert.

>any desire to rely (as an RP) on any representations by the cert's

again, a human being making a value judgement is one thing, but 
developers trying to provide software that evaluates a cert path and 
accepts or rejects a cert do have to worry about what controls are 
offered to a user to affect the evaluation process.

>PKIX cannot tell RPs what to say, trust or even what to believe.

True, but that is not what we are debating.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 07 Sep 2004 15:18:45 -0700

> offered to a user to affect the evaluation process.

An RP should not have to argue with the software, or his computer,
in order to accept or reject a cert.

The software must allow the RP to authoritatively, even against the
software's findings, rely or not rely on any cert. In short, the
software MUST allow any RP to independently rely on or not rely on
any certificate.

You said the same yourself:  "The user as RP should be able to make
these decisions, or his management may do so based on corporate policy.
But if an application embodies these extra-standard decisions [eg, asking
the RP for "reasons"], and the app is not enterprise-specific, then we
have a problem because the application vendor is not the RP and is no
longer representing the wishes of the RP."

Developers trying to provide software that evaluates a cert path
have, thus, a simple task: to implement an "override" control for
the RP. What's difficult with that?

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Sep 2004 16:54:43 -0400

At 3:18 PM -0700 9/7/04, Ed Gerck wrote:
>>developers trying to provide software that evaluates a cert path 
>>and accepts or rejects a cert do have to worry about what controls 
>>are offered to a user to affect the evaluation process.
>

What may be difficult is knowing whether the user invoked the 
override, or some possibly malicious software did so :-)

But, if all you want is an override facility, you are probably not 
helping the user enough.  The user probably wants to know what the 
evaluation process found out about the cert, so that the user is well 
informed if he choose to override the outcome. But, we have no 
standards for what a cert evaluation engine would display to help a 
user in this regard. So, I'm afraid the problem of letting an RP 
override the output of the cert evaluation process is more complex 
that your message suggests.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 08 Sep 2004 16:43:18 -0700

Stephen Kent wrote:
> ...
> The user probably wants to know what the 
> informed if he choose to override the outcome. 

What I'm saying is that if the user chooses not to be an RP for a cert,
the user should be able to freely choose that cert's status (perhaps
from a different service, but that's for the user to choose and implement).
In doing so, when the user is compelled to override the result, why should
the user consider himself to be "well informed" by that same result he is
discarding?

> But, we have no standards 
> for what a cert evaluation engine would display to help a user in this 
> regard. So, I'm afraid the problem of letting an RP override the output 
> of the cert evaluation process is more complex that your message suggests.

Again, if the user decides to override, such decision must come from a parallel
decision channel -- not from that same evaluation process which is being
discarded. For example, if a user receives something as simple as an
encrypted message, the user should be able to decrypt and read that message
even though the cert evaluation engine reports that the cert's status is
revoked -- after all, the sender might have revoked the cert _after_ the
message was sent. Therefore, any information that a compliant evaluation
process could provide (and here might be an opportunity for additional standards
work) is indeed informative but is not so absolutely relevant to that user as
it may seem at first sight.

So, if we do decide that it is desirable (from the very definition of what
an RP must be able to do in order to be an RP at all) to let an RP override the
output of the cert evaluation process, how simple can this be?

Very simple. Let the user manually select from a list of available choices any
of the possible PKIX outcomes at each step, where the cert evaluation engine
may suggest the outcome if the user chooses to be an RP for that cert.

This can be further automated, for example:

1. If the user selects "MANUAL" processing, at every step of the cert path
validation process then the user should be able to override the result, whatever
that result is, before the process continues to the last cert. The overriding
options available to the user should be the same as the compliant options that the
process could provide at each step. This allows the RP to decide, for every cert,
to be or not to be an RP.

2. If the user selects "AUTOMATIC" processing, the cert evaluation engine makes
all decisions as if the user is an RP to each and every cert and presents the final
result to the user. However, even in this case, the user should be able to
override the final result and manually select any of the possible outcomes.
This allows the RP to decide to be or not to be an RP for the entire cert
evaluation process.

The above has nothing to do with implementing or standardizing user choices. The
user does not define the logic; the user chooses the available truth-conditions
for the compliant logic to use at each step. After the user runs such a compliant
evaluation software for a cert, the result reflects the PKIX rules based on the
user-defined RP status for each cert.

Cheers,
Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Sep 2004 09:52:49 -0400

At 4:43 PM -0700 9/8/04, Ed Gerck wrote:
>Stephen Kent wrote:
>>...
>>The user probably wants to know what the evaluation process found 
>>out about the cert, so that the user is well informed if he choose 
>>to override the outcome.
>

I assumed, perhaps in error, that the goal was to allow a user to 
make an informed choice re overriding the cert evaluation procedure. 
If you are suggesting that a user should be free to accept anything 
that someone else says is a cert, which may or may not conform to 
standard syntax and which may or may not be valid using standard cert 
evaluation rules, then this is not a topic for this standards group 
to address.

>>But, we have no standards for what a cert evaluation engine would 
>>display to help a user in this regard. So, I'm afraid the problem 
>>of letting an RP override the output of the cert evaluation process 
>>is more complex that your message suggests.
>

Simplistic, yes, simple, no.

Experience with user interfaces would suggest that the sort of 
process you describe would hardly ever be used, because it would take 
too much effort by a user and would be too complicated for the vast 
majority of users to understand. Your example makes it pretty clear 
how unrealistic this would be.

---

From: Ed Gerck <[email-masked]>
Date: Thu, 09 Sep 2004 12:41:36 -0700

Stephen Kent wrote:

> I assumed, perhaps in error, that the goal was to allow a user to make 
> an informed choice re overriding the cert evaluation procedure. If you 
> are suggesting that a user should be free to accept anything that 
> someone else says is a cert, which may or may not conform to standard 
> syntax and which may or may not be valid using standard cert evaluation 
> rules, then this is not a topic for this standards group to address.

Thanks. As usual, you defined the boundary well. The goal is _not_ to allow
a user to accept anything except that which is PKIX compliant. I am just
suggesting we extend a mechanism that already exists, as I explain below.

So, what happens with a cert evaluation procedure when a user decides _not_
to be an RP [1] for the revocation status of a cert in the path, as defined
by that cert's issuer CA or CRL issuer?

This is the same question facing OCSP and has the same solution:

    the cert evaluation process will ask the user for the status (revoked,
    good, or unknown).

I.e., when the user decides _not_ to follow the conditions defined by the
issuer CA to be an RP for that cert, PKIX can still define an automated,
secure, compliant procedure providing the final result -- as it does with OCSP.

In doing so, the user is not discarding any information provided by the cert
evaluation process. As in OCSP, in allowing a user to provide an input about
a cert's status, that input can also be the single input defining whether the
cert is revoked or not.

What would this input do? The input signals to the cert evaluation procedure
whether the user: (1) wants to use the cert status defined by the cert
evaluation procedure (and be an RP for that cert), OR (2) simply use the cert.
In case of option (2), as in OCSP, the user must choose the cert status from a
list of all possible status accepted by the cert evaluation procedure.

What would be the constraints on applying this user input? PKIX as usual. The
cert must be PKIX compliant, the path validation follows PKIX, etc.

> Experience with user interfaces would suggest that the sort of process 
> you describe would hardly ever be used, because it would take too much 
> effort by a user and would be too complicated for the vast majority of 
> users to understand.

You are right on the face of doing it by hand, but a user-defined cert status
service could handle this automatically. An enterprise-wide policy file could
also be used to provide bars on the choices each user is allowed to.

> Your example makes it pretty clear how unrealistic 
> this would be.

OCSP?

Finally, it seems to me that if the user cannot _choose_ to be an RP, if that
choice is mandated to him for all certs by some software (not by the enterprise),
it could be realistically said that the user is not an RP. What is unrealistic,
IMHO, is to mandate an user to be an RP by force for all certs in the path when
we already have a mechanism (OCSP) that could be extended to accept the user's
input as well.

Cheers,
Ed Gerck

[1] I note that PKIX does _not_ mandate users to be RPs of certs and PKIX does
_not_ limit users to seek revocation status of a cert only from the cert's
issuer CA or CRL issuer. PKIX users can use any revocation status information
source they please and be an RP to them. PKIX users may also just "use" a cert,
being an RP to no one, and still be 100% PKIX compliant.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Sep 2004 13:37:22 -0400

At 12:41 PM -0700 9/9/04, Ed Gerck wrote:
>>make an informed choice re overriding the cert evaluation 
>>procedure. If you are suggesting that a user should be free to 
>>accept anything that someone else says is a cert, which may or may 
>>not conform to standard syntax and which may or may not be valid 
>>using standard cert evaluation rules, then this is not a topic for 
>>this standards group to address.
>

Having just completed a review of your I-D, I know how you 
distinguish between a user as an RP vs. just "using" a cert.  I don't 
agree with the terminology. But, more to the point, any discussion we 
have on this list about a user processing a cert he has received 
should take place in the context of the standards we develop. Once 
you move outside that realm, this WG has no say in what happens, and 
frankly it is not a good use of the list members' time to explore 
such contexts.

>secure, compliant procedure providing the final result -- as it does 

USe of OCSP is part of the cert evaluation process, as an alternative 
to use of CRLs. When SCVP becomes a standard, it will provide another 
standard mechanism for cert evaluation, one that can relieve the 
client of some or all of the burden. But, all of these are STANDARD 
ways of performing cert evaluation.

>a cert's status, that input can also be the single input defining whether the

When a user employs OCSP, it is not the user who provides the OCSP 
response, but rather a server. The server may be operated by the CA 
that issued the cert, making it authoritative, or it may be operated 
by (or on behalf of) the enterprise that provides the user's PKI 
context. In the latter case, a policy on how to acquire cert 
revocation status info has been imposed on the user in his 
enterprise, but it is still not the user's choice.  Now, another 
possible scenario is a user employing an OCSP server as a public 
service, but that seems to be rare, and I think it generally ill 
advised.

The bottom line is that managing cert evaluation is complex, even if 
one is just trying to follow the standard procedures. We find it hard 
to involve the user in a meaningful way, given the complexity of the 
process, and users seem to not want to get involved, in general.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Sep 2004 11:29:20 -0700

Stephen Kent wrote:
> Having just completed a review of your I-D, I know how you distinguish 
> between a user as an RP vs. just "using" a cert.  I don't agree with the 
> terminology. 

What terminology would you suggest? For the benefit of the discussion,
I copy below what I wrote about RPs, which is a qualified user (not any
user). This text comes from a work-in-progress.

2. Relying Party, RP Reliance and Reliance Limitations

    A relying party (RP) is a user who processes a certificate chain, and
    then acts in reliance on the end-entity (EE) certificate issued by a
    CA (the issuer CA) and any associated revocation information.

    RP reliance is a technical term in PKIX. The concept of RP reliance
    is needed in PKIX/X.509 because not every aspect of certificate
    management can be fully verified by an RP. In short, RP reliance is
    that which can break the RP's security policy.

    For example, a user verifying a certificate's revocation status
    (e.g., using mechanisms such as querying a repository or receiving
    notices delivered via a message service) will depend on the
    conforming administration and management of that status by one or
    more authoritative entities -- i.e., the user becomes a relying party
    to these entities.

    More generally, a user who depends on values provided by an entity
    (e.g., CA) that seem reasonable on their face value to the user but
    are especially hard to check by the user is an RP to that entity.

    What does the RP rely on? The RP relies on entities (e.g., the CA)
    following PKIX recommendations that the RP CANNOT verify. For
    example, an RP does not rely on the CA for certificate path
    processing (because the RP CAN verify it) but must rely on the CA for
    ensuring that the CA's signing key is properly secure and not
    compromised. The latter cannot be verified by the RP and becomes,
    thus, a limitation for reliance.

    RP reliance limitations are objectively defined in PKIX, without
    reference to domain policies, user security policy, jurisdiction-
    based rules of laws and contracts or anything else that needs to be
    locally defined.

    As a literal value, RP reliance on the revocation status of a
    certificate is defined by a conforming certificate path procedure
    leading to a bit value -- "revoked" or "not revoked". The literal bit
    value depends both on processes that the RP CAN verify and processes
    that the RP CANNOT verify. The latter defines the limitations of RP
    reliance. The lesser the limitations of RP reliance, the lesser the
    risk faced by the RP that RP reliance might be broken by factors
    outside RP control.

    The literal bit value has no associated semantics outside the scope
    of PKIX. In other words, RP reliance is syntactic, not semantic. Any
    semantic value (e.g., legal reliance, contractual obligations
    concerning use, public policy, etc.) MUST lie outside the scope of
    PKIX and is, for example, regulated by terms in the CA's CPS.

...

3.5 Reliance vs. Use

    An important distinction exists between "reliance" and "use". The
    PKIX standards define the limitations for certificate reliance by an
    RP in terms of a certificate user complying with the issuance and
    revocation conditions for a certificate. Furthermore, PKIX requires
    that compliance must occur through execution of the standardized
    certificate path processing algorithm.

    However, there is no act of non-compliance if an RP simply decides to
    act independently of the authority, with a "use" of the certificate,
    rather than a "reliance upon" the certificate, its revocation
    conditions and its revocation status.  When merely "using" a
    certificate in this sense, the user will normally be ignoring any or
    all the compliance requirements defined in PKIX and/or the authority,
    when processing a chain of certificates and using an EE certificate
    issued by a CA.

Comments are welcome. I will wait with my comments on accepting or not
user input in cert path evaluation.

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Sep 2004 11:53:11 -0700

The last sentence of the last paragraph should have been (from an
updated version):

    When merely "using" a
    certificate in this sense, the user will normally be ignoring any or
    all the RP conditions defined by the authority, when processing a
    chain of certificates and using an EE certificate issued by a CA.

Sorry for the confusion.

Cheers,
Ed Gerck

Ed Gerck wrote:

>> between a user as an RP vs. just "using" a cert.  I don't agree with 
>> the terminology. 
> 
>