Real-world issues, Re: Deprecate the NR bit?

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

This one was screwed up also, for reasons unknown as yet.  Sorry about that.

Bob

--

Ed, I agree with much of what you said, but there is an important case
which you left out, and that is where I as the signer do not trust certain applications,
operating systems, etc., etc., to make use of my "death warrant" certificate keys,
and in particular don't want to ever have such keys generated or stored in software, 
as opposed to a (more) secure smart card.

So it is not only the relying party who may be concerned with such a bit, but the 
signer as well.

Unless the CA is acting as either a notary or an insurance company, I see only a 
very limited role for them in this discussion, however.

Bob

>>> Ed Gerck <egerck@nma.com> 08/31/99 02:07PM >>>


Stephen Kent wrote:

> Not all applications may be trusted to properly assert invocation  of NR
> services.

Failure of NR services  (whatever "NR services" is understood to be, from
the options mentioned here) will  however flow back only to the
relying-party *if* the relying-party uses an application that causes that
failure by improperly asserting invocation of "NR services" -- which is
what you mention above.

Therefore, in the case you mention, both the cert  issuer and the cert subject
will be *relieved* of any "NR services" obligations -- which means that
is irrelevant to either of them whether the relying-party fails or not fails
to use an application that can "be trusted to properly assert invocation of
NR services".

This logic applies also when the issuer entity has a second hat as one of
the relying-parties -- for example, when the CA is internal to a company
and has the responsibility of selecting the application that will be
used to validate the certs at the workstations, because in this case the CA
is not acting as an issuer in this second role but as a relying-party to the
issuer and its failure in this second role cannot taint its first role as an
issuer.

Thus, the case you mention is moot in real-world cases -- it is the
relying-party's responsibility to select its applications, and also to use
them properly.

> By including the NR bit in a cert, we have a (potentially)
> higher assurance mechanism that can allow or prohibit an application from
> invoking NR services.

Agreed 100%. Whatever "NR services" is.  But that decision (to allow or
prohibit) can fall on the relying-party itself, on the cert issuer, on the cert
subject or on a fourth-party (validation service, etc.).   Thus, what you
mention needs to be expressively qualified -- either in the spec or in the
CPS, or in both (with default to CPS). I prefer the last option, for reasons
already mentioned.

Without qualification, what you mention is thus too ambiguous to be
useful in the real-world.  And, illegal if there was no previous provable consent
based on clear text with a choice not to use it.

>  For example, if one provides an application with
> access to certs ONLY with NR=0, we can ensure that these apps cannot assert
> that they are acting in an NR capacity on behalf of the user.

In your example, "one provides an application with access to certs ONLY
with NR=0" is a trust statement.  Someone trusts that "ONLY" -- either the
"one" that provided (e.g., a sysadmin) or the relying-party itself.  However,
what happens if that application may not in fact be properly trusted in the
real-workd operational context? Then, we are back to paragraph one.   So,
"we can ensure" nothing.

Again, it is the relying-party's responsibility to select its applications, and
also to use them properly.

> This is a very useful security facility and a good reason to keep the NR bit.

Not by this reason, though, as above.

Further, I think that is becoming increasingly clear by these and previous examples
that there is no real-world use model behind the "NR services" defined in PKIX.
And I say this not as an argument to deprecate the "NR bit" (which would be the
worse choice IMO) but as a strong argument to say the least about it in the spec
itself and leave the CPS as the authoritative source -- possibly with a simple
and clear default behavior in the spec if the CPS does not mention it.

To be fully backward and forward compatible  is not easy in this case but
suggestions were already presented.

BTW, as a side remark but also a real-world issue, it may be time for IETF to
also consider WG-authored RFCs and STDs -- which would avoid the problem
of one or a few authors being  confronted with the unfair pain of changing
their own words based on a large WG's work with many more eyes.   It is hard
to imagine RFCs on important and wide-reaching subjects that can really be
attributed to one person nowadays, even though this was possible some
Internet-years ago with John Postel and others.   If decisions are made by or
imply consensus and if there is wide  participation, attribution of RFCs to the
WG should afford more flexibility and actually reflect that participation.  One
recent example where this is being applied quite successfully in a difficult
subject can be seen in NSI's Registry Advisory  Board where I participate
and we decided to use anonymous attributions in the Meeting Minutes in
order to stress that they are the result of group work and to keep positions
flexible -- nonetheless, we can keep track of what has been decided and why.
The mechanism of group-authored text can be extended even to list discussions
as one Internet WG used in order to enhance the flow of ideas, by anonymizing
email addresses. Group-authored text can also be reduced in RFCs by selecting
one or two WG members as editors of contributions but not as writers.

Cheers,

Ed Gerck