Subject: RE: To Be, or NR To Be ...

From: Elliot Ginsburg <[email-masked]>
Date: Mon, 23 Aug 1999 16:00:19 -0400

A security policy within a security domain is intended to give assurance
to the consuming population that they can place a certain level of trust
in the use of PKI credentials issued under this policy, providing that
all parties adhere to the policy; remember that a policy has user and
relying party obligations as well as CA obligations. Part of the
obligation is to use the credentials for their intended use, as asserted
in the cert. If you don't assume this obligation, you are in violation
of this policy and you will be incurring a level of risk higher that
what has been assured by this policy. 

Probably someone can say this better, but I think that is the gist of
it.

Since we also have to deal with the difference between critical and
non-critcial keyUsage, I'll try the following:

If NR==0 and keyUsage is marked critical, then it is a violation of this
CAs policy to use this certificate for NR, and the level of risk
incurred is undefined, and this CA is not liable for the consequences of
this usage.

If NR==0 and keyUsage is marked non-critical, then this domain advises
not using this cert for NR, because the incurred risk is higher than
intended for this policy, but does not prohibit it's use; this must be a
judgement of the user based on the nature and circumstances of its use.

If NR==1, and keyUsage is marked critical, then this CA intends this
cert to be used as part of an NR service, and not for other uses, and
warrants it only for NR use in accordance with the stated policy. (See
section 12.2.2.2 for the guidance on using these bits in a mutually
exclusive way. (3:50 PM 8/23/99DS is for other uses, and it may also
need definitions like this).

If NR==1, and keyUsage is marked non-critical, then this CA intends this
cert to be used as part of an NR service, and warrants it for that use
in accordance with the stated policy, but does not prohibit it from
other uses; it is, however, intended that other certs would be used for
these other purposes.

This still leaves the question of what does non-repudiation mean. If we
are willing to say that it implies that the CA offers the
non-repudiation service (which I support), then it can be called NR.
Otherwise, I agree with Ed that it needs to be renamed. 

What I'm most concerned with is that we agree on a very tight statement
of semantics, regardless of how narrow or broad this statement is. (BTW,
section 12.2.2 implies that authentication and integrity services are to
be distinguished from NR service).

Elliott N Ginsburg
CygnaCom Solutions
[email-masked]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	Tony Bartoletti [SMTP:[email-masked]]
> Sent:	Monday, August 23, 1999 2:12 PM
> To:	Elliot Ginsburg; tog; Stephen Kent
> Cc:	[email-masked]
> Subject:	RE: To Be, or NR To Be ...
> 
> At 08:47 AM 8/23/99 -0400, Elliot Ginsburg wrote:
> >Since the CA sets these bits, we have to decide what the CA is
> asserting
> >when it sets or doesn't set a bit. Just as we have decided that when
> the
> >CA asserts a policy OID, it is saying that it created this cert
> >according to the named policies. When I use that cert, am I asserting
> >something about policy because I used it? I don't know, but I do know
> >that the CA did make an assertion.
> >
> >So what does the CA assert with the NR bit? One possibility has been
> >mentioned already for the meaning of the CA setting the NR bit, and
> that
> >is whether this cert can be used for non-repudiation. Its one thing,
> >when I get a message, to trust who sent it and the integrity of the
> >content; its quite another to be able to verify this five years from
> >now. So I, as a CA, might tell you that this cert is usable now, but
> >don't come back to me in five years, because I do not run a
> >non-repudiation service. Which would imply that if the NR is set,
> there
> >is an assertion that this cert was intended to be used for
> >non-repudiation and can be relied on for that, however
> non-repudiation
> >was defined in the policies of the CA. As a relying party, I will not
> >store this message away and assume I have proof of the signer's
> actions
> >if the NR bit is not set.
> 
> Elliot,
> 
> The point Ed Gerck was making (about 100 posts back;) was that the CA
> can only say "I will/won't cooperate with the use of this cert for NR
> purposes."  E.g., If the NR-bit is not set, we don't archive old
> stuff.
> 
> But others that are party to the original transaction are still free
> to archive the signing cert, CA cert, CA Public Key, CRL's etc., and
> present them in court in the case of a dispute.  Who knows how far
> this will get them.  But it has been written on occasion that if the
> NR-bit is not set, then the CA is saying "you cannot use this cert for
> NR", and that is not necessarily true.
> 
> I agree with you, as Ed has also stated, that the CA controls the cert
> issuing process, and so it is the CA making an assertion, directly.
> 
> 
> ___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: "Peter Williams" <[email-masked]>
Date: Mon, 23 Aug 1999 13:49:47 -0700

Bundling NR services with a CA should be one option: it
is not realistic to require that only CAs be able
to provide access to a value-added NR service, once the
user has invoked a proof of origin/receipt service. Nor is
it reasonable to require CA performing the authentication
portion of a NR-grade security service to also
always offer the complete set of transactional
NR assurances.

In the NACHA CARAT PKI model, repository service providers (who
are distinct from the CA(s)) are sufficiently trustworthy to 
act as source of status information, and also act as one 
of the parties that a relying-party may use when
seeking technical and registry support in an NR dispute.

There are some CA service vendors who would like to outlaw
the NACHA model; the reasons seem mainly about competitive
marketing. I would encourage that the wider model be embraced,
understanding that a Repository and CA service may be
be co-located in a single provider.

If Tom and your material could be put together in an ID,
we may be on the way to an IETF specification of technical
NR, and the semantics of the NR bit, in the PKIX 2459 profile.

An evaluation of whether this will meet the PKIX-QC needs, 
where NR assurances must meet CEC (not merely PKIX technical) 
regulatory requirements, will have to wait a while.

> From: Elliot Ginsburg [mailto:[email-masked]]
> Sent: Monday, August 23, 1999 1:00 PM
> To: Tony Bartoletti; Elliot Ginsburg; tog; Stephen Kent
> Cc: [email-masked]