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

["Peter Williams" <peterw@xxxxxxxxxxxx>]

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.

> -----Original Message-----
> From: Elliot Ginsburg [mailto:ginsburg@cygnacom.com]
> Sent: Monday, August 23, 1999 1:00 PM
> To: Tony Bartoletti; Elliot Ginsburg; tog; Stephen Kent
> Cc: ietf-pkix@imc.org
> Subject: RE: To Be, or NR To Be ...
> 
> 
> 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
> ginsburg@cygnacom.com
> 703-848-0883
> 703-848-0960(FAX)
> 
> > -----Original Message-----
> > From:	Tony Bartoletti [SMTP:azb@llnl.gov]
> > Sent:	Monday, August 23, 1999 2:12 PM
> > To:	Elliot Ginsburg; tog; Stephen Kent
> > Cc:	ietf-pkix@imc.org
> > 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: azb@llnl.gov                                   LLLLLLLL