Subject: Subdividing the NR bit.

From: [email-masked]
Date: Fri, 20 Aug 1999 16:23:00 -0600

Tony, I was thinking about your classification of the uses 
of the NR bit some more yesterday and this morning, and 
my recent response to Tom Gundin and your message has 
crystallized my thinking some more.

I was already concerned about the possible dual meanings of 
NR bit, as that is generally not a good thing architecturally.

So let's temporarily set aside the issue of the "Rebuttable 
Presumption" or "intent" functions, and concentrate solely 
on the classical, DOD/ISO view of the "non-repudiation 
service" function.

Since that definition doesn't seem to lay any "thou shalt's" or "thou 
shalt not's" on me as a developer, I'm rather clueless as to 
exactly what I am supposed to do or not do when I see or
don't see such a bit.

But poor draftsmanship aside, what is it that we think it OUGHT
to do?

One possible meaning is:  This is a really big and important 
certificate, for really big and important messages, so anyone
who sees it ought to run off to the CA and gather up all of the 
CRLs for all of the CAs in the chain, get them timestamped, 
archive them along with the message, etc., especially since 
you might need to validate this signature some time after 
the certificate expires.

But Duh!  As a relying party, I can decide that for myself, 
whether the bit is turned on or not.  "Oh golly gee, this is a 
$1 million transaction that doesn't have the NR bit turned on.
Guess I ought to gather up all of the important evidence anyway."

Or, "This is just a receipt for a 25 cent candy bar. I don't know why 
NR bit was turned on, but I will have eaten the candy bar before 
I can gather up all of the evidence, so I'm not going to bother."

Net information content added -- zero. Nothing I couldn't have 
decided for myself, in either case.

So it doesn't help the relying party.  How about the subscriber?
Well, maybe.  Maybe he gathers up all such evidence for outgoing
messages that have the NR bit turned on in the certificate, just so
hell have it in case he needs it.  But there are surely other ways of 
doing this, including a bcc to an archive, and always gathering up a 
timestamped copy of your own CRL once a day.  Again, not 
very convincing, whether the bit is on or off.

So how about the CA?  Of course, I don't know why the CA 
was involved in this in the first place, unless they are offering 
to insure the transaction, in which case a policyOID is a much 
better mechanism (insured by whom, for how much, and with 
what provisos -- a bit much to cram into a single bit.)

Maybe they feel the need to do a better job of due diligence
for such a certificate? OK, but why the bit -- it's just a different 
certificate class.

Likewise, maybe it has something to do with the key strength, or how 
it's stored?  Again, a single bit is a lousy mechanism for such an issue.

Maybe it means that as a subscriber I should be really careful not to 
let anyone else have access to the key, but again, Duh.

Maybe it means that both the subscriber and the CA should make 
sure that the key isn't subject to key escrow or business key recovery.
But the DS bit would be sufficient for that, presumably -- a separate 
bit would not be required.

Since I'm not a supporter of this meaning, I admit that I might be 
missing something.  But so far, within the restricted context of the 
traditional non-repudiation service, ignoring such issues as rebuttable
presumptions of either burden of proof or risk of loss, or conscious intent,
I can't think of anything this bit provides where it is either necessary 
or sufficient, whether it is set or not set.  And that is a long-winded 
way of spelling USELESS.

But in this connection, Peter Williams proposed that:
>>>
>> In the specific case of the Authenticode example, I agree that it might be
>> reasonable to amend 2459 to allow the NR bit to be set as well as the DS
>> bit.
>
>This was discussed before, and the list agreed with
>my assertion then, as you evidently do now. Unaccountable
>offline msgs got the bit removed, presumably.

And Steve Kent responded:

>I don't recall that "the list agreed" on this topic, but then the length of
many of your messages precludes reading them to the end :-).  If the 2459
authors agree, then we're OK.

At the risk of getting both Peter and Steve irritated with me but perhaps
for different reasons, I'd like to understand what the NR bit is thought 
to accomplish, before we add it back in.

Unless someone can come up with something I've overlooked in this
area, I would propose that we nail this particular coffin shut, and 
move on to the intent to use and strength of key issues that Tony cites.

Bob

>>> Tony Bartoletti <[email-masked]> 08/20/99 01:21PM >>>
All,

There is a central point to this debate.  There appears to be two
distinct positions held, in particular to the meaning "NR-bit NOT SET".

Strength 0f Intent:
Some say this means "I signed it, I intended to sign it, but I do not
intend its use beyond pure authentication of data and sender, and that
specifically *I* am not signalling assent to be legally/contractually
bound by any terms contained in the data."

Strength Of Key-Binding:
Others say it means "I may not have signed it.  The key protections for
this key do not warrant any presumption that its use is restricted to
the individual given as the certified owner."  Its not a "strong-enough"
key for the purposes of NR.

Clearly, these two meanings are WORLDS apart, and cannot both be called
"the meaning of NR-bit NOT SET".

Part of the confusion is that these two meanings are not entirely
unrelated.  It would make no sense to assert "assent to legal binding"
with a key that is weakly-held.  In a sense,

  weakly-held-key < strongly-held-key < strongly-intended-signature

and some want "NR-bit 0" to disavow only "strongly-intended-signature"
while others argue it disavows "strongly-held-key", which then takes
"strongly-intended-signature" down with it.

There are probably good arguments for both positions.  But it is
clear to me that there cannot be ambiguity as to which of these
two positions is being asserted.

Comments?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 20 Aug 1999 18:00:36 -0700

At 07:39 PM 8/20/99 -0400, [email-masked] wrote:
>     Here are two points where it might not be useless from a purely technical
>standpoint:
>
>1)   The passage from X.509 I quoted earlier about a CA's responsibility for
>archiving CRL's governing certificates explicitly refers to support for the NR
>service.  So one current technical use is: a CA is responsible for archiving all
>CRL's governing any NR certificates, or at least the last one prior to the
>expiration of any NR certificate.  This probably should be extended to hold a CA
>responsible for archiving any expired NR certificates as well as CRL's.
>
>2)   The NR bit might be held to govern whether a signature should ever be
>applied to a preservable, independently verifiable signature package.  I don't
>have any idea what technical NR means if it doesn't refer to the creation of
>such a package including signature (and perhaps to the verification of the
>package as well, but I see that as a subsequent step which is usually not
>invoked, although making it feasible is the motivation for the service in the
>first place).  Does anybody have any other idea what technical NR means?
>
>3)   Even if only #1 is applicable to NR certificates, it would be a
>considerable reason why nobody should rely on a non-NR certificates for a very
>high-value transaction where the signature is likely to be needed in court in
>the event of a dispute, unless the validity period runs beyond the local statute
>of limitations.
>
>          Tom Gindin

Tom,

I tend to agree.  So far, the only real description of "Technical NR"
I have seen is "You better archive/timestamp/notarize this stuff, 'cause
it may be important later."

Beyond this, I thought about a hierarchy of possible "repudiations"
and wondered just what means would be needed (pre-sig and post-sig)
to support (protect against) them:

1.  Not My Key:  (argue a forged cert request)

2.  Not My Usage:  (key compromised, etc.)

3.  Not My Active Usage:  (Automated process made the signature)

4.  Not My Willful Active Usage:  (gun to my head) 

5.  Not My Intent To Sign THAT:  (False Content Displayed for Signature)

6.  Not My Intent To Be Bound:  (That was a Contract?)

Now, in each case, imagine the NR-bit is set in the certificate, and
the relying party duly gathers up all evidence for archive.  How much
protection can this afford against each of these repudiations? 

For #1, I think that the RP should retrive and archive, from the CA,
the photograph taken of the subscriber shaking hands with the CA President,
a banner in the background stating "Another Fine Customer Purchases an
NR Certificate, Public Key xxxxx, Date yyyyyy", such photograph digitally
signed and cosigned by both the CA and subscriber keys, and perhaps
digitally watermarked with these keys as well.  A voice-print of the
subscriber reciting the CA/CPS verbatim would be another good piece
of evidence to archive.

Any Ideas about repudiations 2-6 ?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL

---

From: "Aram Perez" <[email-masked]>
Date: Mon, 23 Aug 1999 10:32:52 -0700

Hi Bob,

[snip (but only to keep the message short)] 
> or sufficient, whether it is set or not set.  And that is a long-winded

I couldn't have stated it better.

Regards,
Aram Perez

[snip]