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

[Alex Deacon <alex@xxxxxxxxxxxx>]

Hi Peter, 

"Registering user agents" should not make any assumptions as to the contents
of the various cert bags in use today.  A CA (or RA) may choose to include
what it beleives to be a set useful certificates that the client will need
to perform proper chain validation.  In some cases, such as CMS, CRL's may
also be conveyed. 

However the CA or RA makes no assersitions as to the reliability/validity of
these objects.  From what I understand of the classic X.509 model, it is
always up to the client to determine the validity certs.   A client may
choose to utilize the certs provided in these cert bags, however it may also
decide to drop them on the floor and use other methods for cert (and crl)
discovery such as LDAP and other methods of certificate validation such as
OCSP.  I would guess that the pki policy under which these clients operate
would influence these kind of decisions....

Alex

-----Original Message-----
From: Peter Williams [mailto:peterw@valicert.com]
Sent: Wednesday, April 19, 2000 12: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