RE: What is the order of certificates in a certificate chain?

[Peter Williams <peterw@xxxxxxxxxxxx>]

Hi Carlisle:

Its always fun to consider the interaction of technical
specification, the role of technical compliance, and the 
policy rules which govern how technology operations
MUST function. Let us address this topic a little more
for the case of validating EE certificates during certificate
acceptance.

One of the things that many reference CPSs require, and Santosh'
and Warwick's (http://www.ietf.org/rfc/rfc2527.txt 4.4) work on CPS 
disclosures highlights,is the notion of "certificate acceptance" by 
subscribers. 

Acceptance is the point where the good work of the CA 
(via CMP or PKCS or Cisco's protocols) in registering and certifying 
public keys (and other data) is checked by the subscriber. This is done
normally PRIOR to publication of the certificatein a repository that then
perform the initial and then ongoing certificate 
management.  Various legal obligations may be passed at the moment 
of acceptance; it is an important step in the legal protocol. Generally, one
 is not authorized to use or rely on the certificate as a 
subscriber - until one has accepted it. 

Certificate acceptance is *specifically* relevant to 
the protocol message under discussion, I would suggest; it is 
the generalization of what CMP is enforcing when the
EE UA accepts/processes the cert response msg. The content
of that response is the specfiic question.

The rules for acceptance of the EE cert are policy-based, of course.

https://www.verisign.com/repository/CPS1.2/CPSCH7.HTM#_toc361807047
specifies one such policy rule system, into which a particular 
configuration of CMP would presumbably have to fit. It is not CMP
that drives policy design; policy drives how CMP is used
to satisfy the technology-independent/protocol-independent
policy rules.

In general, "reasonable acceptance" require a susbcriber validate 
the certificate upon initial receipt - after all, its
signature may fail verification, or the data contained
within may be erroneous, or, you just change your
mind about binding yourself to the CA's legal agreement.
In policy-cases such as VeriSign, furthermore, **only
upon** acceptance may the next phase of CMP go ahead
wherein the certificate is published to the primary
and official respository by the CA's CMP instance.

Now, my claim is, surely with very significant
relevance, that the only way to validate an EE cert 
at the moment of acceptance, is to traverse some trust 
chain upto a trust-anchor.

If I understand CMP and the conversation here,
it is understood that the pubKeys data element will
communicate those certified keys that the EE needs to validate
its own key, during acceptance and/or at later
points of time.

>From you mail, it is now implied that the same
EE UA may be required - at the point of acceptance
(namely processing the CMP Response) - 
to obtain CRLs from one or more CAs via CMP, so that
it can indeed validate the certificate it
has just been sent for acceptance, and
(as necessary) confirm the supporting
cerificate chain as required by such
as VeriSign's policy.

https://www.verisign.com/repository/CPS1.2/CPSCH8.HTM#_toc361807054
(see 8.2 for discussion of confirmation, and validation)

At this point, we have one further
techno/policy question. In supplying the
certs necessary for EE cert validation at
the point of acceptance, whose nature largely
**determines** the outcome of acceptance,
what liability does the CA have for
inducing that outcome?... particularly
if it supplies compromised CA certs 
which are revoked or no longer
in good standing in an accreditation
registry?

Peter.

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: Wednesday, April 19, 2000 1:17 PM
To: 'Alex Deacon'; 'Peter Williams'
Cc: PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?


Hi Peter,

Good to hear from you again!

I apologize in advance if I appear unsympathetic to your line of
questioning, but I'm afraid it seems a little bit irrelevant to me.  In most
environments, prudence dictates that you check the validity of a certificate
just prior to using it (i.e., relying upon it), not upon first receipt of
it.  Therefore, in your emphatically fictitious example (!), even if
Verisign wished to attest to the reliability (in some sense) of the supplied
cert path, who is to say that this path is still reliable 10 minutes later
when the newly-initialized EE wants to perform some other action?  (A new
CRL might have been published by then listing one or more of these certs as
revoked, or the relevant OCSP responder might give a negative answer due to
a notification of key compromise.)

I can't think of any way in the spec. for the CA to perform "an
authoritative, legal introduction to the entites bound to the public keys",
as you put it.  Nor do I really think there should be.  The purpose of the
supplied bag of certs is to provide helpful information to the EE (e.g.,
"here are the CAs between you and the trust anchor", or "here are the keys
of some other entities that may be useful" (such as a time stamp server, or
an OCSP responder, or whatever)).  When the EE needs to rely on these keys,
it should get the relevant CRLs/ARLs, or contact the relevant responder,
etc., just as it would for any other certs.

Note that CMP does define a CRL request message and a CRL announcement
message that may be used for EE discovery of revocation information, but not
much explanation or detail is given on these messages.  This is primarily
because such functions are more properly the domain of the PKIX operational
protocols, which are specified separately.

Carlisle.


> ----------
> From: 	Peter Williams[SMTP:peterw@valicert.com]
> Sent: 	Wednesday, April 19, 2000 3:12 PM
> To: 	'Alex Deacon'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
> Alex,
> 
> Some issues:
> 
> Should implementors assume that there are "any
> particular certificates in the caPubs field" - or should
> one assume it may be a "random" bag of any certs
> the CA chooses to send?
> 
> As far as the normative CMP spec is concerned, a registering 
> UA can make no assumption as to the certs that a CA
> populated in caPubs. One cannot build
> a "conforming UA" to expect "a subscriber's 'cert path' up
> a trust hierarchy" for example - as neither all 
> CMP conforming implementations nor
> the Certification domains to which the CMP module provides
> service may provide this optional, highly policy-specific 
> construct.
> 
> Now, consider the other side of the coin.  Assume
> a CA's configuration of a CMP implementation chooses to
> send a given set of certificates - out of which one can form 
> a "trust path",  where the CA's policy defines what a "path" 
> is for use in policy-compliant "certificate validation".
> 
> Does a CA who sends such certificates to a user
> bear responsibility for the current, individual reliability
> of any certificate is sends? I.e.
> can one assume that the subscriber's CA has just checked the 
> certs' non-revoked status, or the provider's contiuing
> accreditation certificate status, under the CA domain's or 
> another regulators governing policy, prior to inducing others 
> to use or rely on those certificates.
> 
> Surely, by virtue of supplying CA certifificates to a subscriber
> at such a critical juncture one is performing an authoritative,
> legal introduction to the entites bound to the public keys?
> 
> 
> Scenario:
> 
> Lets take a scenario, mostly real - which flexes
> the 2459 and CMP model according to these issue
> to see if it all really works when we get out of the 
> realm of paper architectures:
> 
> I enroll for a VeriSign class 1 cert as a subcriber,
> for the (fictional?) "US govt interoperable" type of 
> key certification service.
> 
> Half the reason I, the subscriber, choose VeriSign - versus any 1 of 
> 1000 other (otherwise) equivalent providers of certs - is because 
> US govt. has (FICTIONALLY) accredited VeriSign Class 3 operations, and 
> (FICTIONALLY) recognises Class 3 organizational certs for ... some
> important,
> high-value G2B application.
> 
> Now I assume that a VeriSign-policy specific CMP registration response
> would send me, in bag order, at least the various
> non-PCA intermediate CA certs from VeriSign's trust hierachy,
> plus the cross-certificate issued by US gov to
> the VeriSign Class 3 PCA. After all, this is what I really
> need.
> 
> If VeriSign does send me such an authoritative cross-certificate, can I 
> assume its (a) valid and (b) the recognition (accreditation)
> status of VeriSign Class 3 PCA domain, before US govt, is
> in good standing at that moment? 
> 
> Do I need to check revocation status of the cert before making
> such a judgement, in counterpoint?
> 
> Similarly, if VeriSign (my choice of TTP provider) sends me a 
> subordinate CA certificate that corresponds to a non-VeriSign 
> operator (British Telecommunications, say) is that an implied
> representation that the operator is in current compliance with 
> VeriSign's CPS/policy, and I can rely upon that implicit signal?
> 
> 
> Summary of questions:
> 
> Surely, to summarize, 
> 
> (A) A TTP-grade CA would only send a 
> critically-important certificate that is "reliable" - characteried 
> by actual and current compliance with policy, accreditation, and similar
>  programs that denote an operators trust standing in the eyes of auditors
> and similar independents?
> 
> (B) To check such certificates for reliablity, would one
> need access to the various CRLs, or similar status
> sources. Should CMP be supplying these, too? Or, do
> we assume the registering UA will do a (not CMP-specified)
> action to collect and process those CRLs before completing
> the registration process, and formally "accepting" the supplied
> subscriber (EE) certificate and the ancillary caPubs or
> other similar information needed to validate that certificate?
> 
> Peter.
> 
> -----Original Message-----
> From: Alex Deacon [mailto:alex@verisign.com]
> Sent: Wednesday, April 19, 2000 11:05 AM
> To: 'Christopher Williams'; PKIX Mailing List
> Subject: RE: What is the order of certificates in a certificate chain?
> 
> 
> 
> I dont think any order should be assumed.  Your code should handle cert
> chains included in a registration response message a "bag of certs".
> Making assumptions as to the order of certs in structures designed to hold
> cert chains  (i.e. a SEQ of certs, such as the caPubs structure) is
> probably
> a bad idea and will only cause interop problems down the line.
> 
> Alex
> 
> -----Original Message-----
> From: Christopher Williams [mailto:ccwilliams@ntlworld.com]
> Sent: Tuesday, April 18, 2000 8:41 AM
> To: PKIX Mailing List
> Subject: What is the order of certificates in a certificate chain?
> 
> 
> If, for example, a CA provides a certificate chain in an initialization
> response, in which order should it add the certificates?  Its own
> certificate first or root CA certificate first?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com
>