RE: Deprecate the NR bit?

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Paul,

X.509 (and thus also RFC 2459) does define semantics for the NR bit, up to
a certain point.

X.509 Annex B, section B1 defines the service non-repudiation as:
"Non-repudiation:  This service provides proof of the integrity and origin
of data  both in an unforgeable relationship  which can be verifed by any
third party at any time."

As RFC 2459 is a profile of X.509, this definition applies to RFC 2459 as well.

Now, this level of definition is not sufficient for all higher level
contexts but that doesn't make it useless. It just means that the full
semantics of this bit (service) must be combined with some policy
definitions (implicit or explicit). It still work fine as a switch saying
that 1)the basic definition above and 2)these higher level policy
definitions, apply to this cert.

And actually this is also the case with other key-usage bits as well as
other parts of X.509 certificates.

So what I mean is that PKIX should not go into more detail than what X.509
already does. In fact, doing so would be incompatible with X.509, and that
would be to go against the PKIX charter.

/Stefan

At 01:43 PM 8/27/99 -0400, Paul Koning wrote:
>Let me see if I understand this.
>
>Stefan says that PKIX can't, and shouldn't try to, provide a common
>understanding of what NR is.  
>
>Stefan and John both say that the semantics of the NR bit aren't
>defined in PKIX, they are defined by what lives above and vary
>depending on what lives above.
>
>And David says that they have semantics for the bit but they are
>different. 
>
>So in summary, PKIX can define the bit but it can't define what it
>means, and if you ask what it means you will get either no answer or a 
>variable answer.
>
>That does suggest to me the bit doesn't belong here.  Let it go into
>the applications that have a defined semantic, with a name appropriate 
>for its meaning, and a definition of its meaning.
>
>	paul
>
>>>>>> "Fillingham," == Fillingham, David W <dwfilli@missi.ncsc.mil> writes:
>
> Fillingham,> I agree with John and Stefan that the NR bit not be
> Fillingham,> deprecated, for the reasons they indicate, and because
> Fillingham,> the current draft DoD Certificate Policy has slightly
> Fillingham,> different requirements for certificate generation and
> Fillingham,> management for digital signature certificates that do or
> Fillingham,> do not assert the non-repudiation key usage bit.
>
> >> ---------- From: Linn, John[SMTP:jlinn@securitydynamics.com] Sent:
> >> Friday, August 27, 1999 12:38 PM To: 'Stefan Santesson' Cc:
> >> 'ietf-pkix@imc.org' Subject: RE: Deprecate the NR bit?
> >> 
> >> I agree with Stefan.  While an NR bit is appropriately sourced
> >> within a PKIX infrastructure (representing, in a protected manner,
> >> an assertion by an issuing CA), it's primarily consumed above the
> >> infrastructure.  Its consumption and semantics will depend on
> >> operational environments and their policies.
> >> 
> >> Consensus hasn't yet become apparent on identifying all of the
> >> characteristics which PKI-supported NR services might possess, or
> >> in organizing those characteristics into an ordering. 
>
>> From: Stefan Santesson [mailto:stefan@accurata.se]
>>
>> I must admit that I have not followed everything said
>> regarding the NR-bit
>> on this list, but I'm not surprised that PKIX can't provide a common
>> understanding on what NR is in detail.
>>
>> In fact I don't think PKIX should even try to do that, other
>> than in the
>> very general context that has already been done in RFC 2459.
>>
>> This does not mean that the bit is useless and should be
>> deprecated. The NR
>> bit belongs in a much wider context totally above the PKIX
>> level. The fact
>> is also that the NR-bit is used in many higher level context
>> with success.
>> If you would deprecate the bit you would force them to be
>> non-compliant to
>> PKIX.
>>
>> It is up to higher level of system design to provide the
>> exact semantics of
>> this bit, presumably in combination with some defined
>> electronic signature
>> policy. And then its up to the lawyers and judges to judge
>> the outcome of
>> this higher level context.

-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------