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

From: "Christopher Williams" <[email-masked]>
Date: Tue, 18 Apr 2000 16:41:02 +0100

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

---

From: Alex Deacon <[email-masked]>
Date: Wed, 19 Apr 2000 11:05:17 -0700

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:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

Christopher Williams

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 19 Apr 2000 14:40:02 -0400

Hi Chris,

Alex is right:  no order should be assumed.  See, for example, the note
explicitly stating this in the last sentence of Section 3.1.  This lack of
constraint on cert order should be assumed to apply in all similar fields
(e.g., caPubs).  I guess I didn't think this needed to be repeated
throughout the document because people would already be familiar with this
practice from S/MIME (CMS) and elsewhere.

Carlisle.

> ----------
> From: 	Alex Deacon[SMTP:[email-masked]]
> Sent: 	Wednesday, April 19, 2000 2:05 PM
> To: 	'Christopher Williams'; PKIX Mailing List
> Subject: 	RE: What is the order of certificates in a certificate
> chain?
> 
>

---

From: Peter Williams <[email-masked]>
Date: Wed, 19 Apr 2000 12:12:15 -0700

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:[email-masked]]
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?

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

Christopher Williams

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 19 Apr 2000 16:17:10 -0400

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:[email-masked]]
> Sent: 	Wednesday, April 19, 2000 3:12 PM
> To: 	'Alex Deacon'; PKIX Mailing List

---

From: Peter Williams <[email-masked]>
Date: Wed, 19 Apr 2000 16:35:20 -0700

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:[email-masked]]
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,

Carlisle.

---

From: Alex Deacon <[email-masked]>
Date: Wed, 19 Apr 2000 16:39:39 -0700

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:[email-masked]]
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:

Scenario:

Summary of questions:

Surely, to summarize, 

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
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?

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

Christopher Williams

---

From: Peter Williams <[email-masked]>
Date: Thu, 20 Apr 2000 19:57:30 -0700

Hi David:

Consider the following reasoning:-

A CA, in the PKIX model, may be accredited - something
that is signaled via the issuance of a cross-certificate
or similar.

If a (trusted) CA quotes such a cross-certificate during
certificate application procedures, it is
essentially representing the validity of the underlying
accreditation. A CA which quoted a revoked
accreditation cross-certificate would
be likely acting in a manner which is a mis-representation
of fact, surely.

If a building contractor came to your house,
presented an official and legally-recognised
paper license to do electrical work, and you subsequently 
determine that the license had been revoked in
the license registry prior to presentation of the
paper during contract negotiation, would you not feel a 
simple mis-representation had occured?

Could a regulator not punish that contractor for
not suspending licensed work - and/or falsely
imputing a licensed standing?

I would think that a best practices Internet CA has 
a simple professional if not a legal duty to ensure that
it does not provide false information to a subscriber 
during CMP; especially information that might prejudice 
the determination of that subscriber when establishing 
the initial accuracy of a certificate that will bind 
him/her at NR grade of proof - following formal 
acceptance of that certificate.

----

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Thursday, April 20, 2000 8:32 AM
To: [email-masked]
Subject: RE: What is the order of certificates in a certificate chain?

> From: Peter Williams <[email-masked]>
> 

Surely, one is not.  The bag-o'-certs is *nothing* more than a
pile of information that may save the subscriber the effort of
looking them up in a directory or elsewhere.  It is entirely
up to the subscriber to choose a trust anchor and validate all
certs from that anchor.  If one or more provided certs cannot
be so validated, I don't see how they can be regarded as
"introduced" or "considered reliable by a TTP-grade CA".

What, precisely, is a subscriber supposed to do with intermediate
(non-self-signed) certificates which have been "introduced" by a CA?

Dave

---

From: Peter Williams <[email-masked]>
Date: Thu, 20 Apr 2000 20:01:15 -0700

Alex,

We have seemingly cleared up or determined
three technical points from the discussion. Do
say if any description below is not
correct - in your view.

(1) a CMP responder does not need to send any
particular cert path to the subscriber, when
returning the EE cert for EE acceptance. The UA
should not assume presence of any particular
certs, including the CA cert or any superior
certs in the domain's trust network, in the 
message field in discussion. Futhermore, any
certs that are sent are in bag order.

(2) According to CMP designers, the UA does not
need to verify the signature of the 
EE certificate upon initial receipt (which
in many enrollment circumstances will constitute the
moment of making an acceptance determination.) Such
UA does not therefore need any certificate
paths or CRLs ( or othe status source) at that 
point in time.

(3) CMP's CRL retrieval service is not meant
to be a PKIX operational protocol. It is not
clear if a conforming CMP implementation and CA
will provide this facility.

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 4:40 PM
To: 'Peter Williams'; PKIX Mailing List
Subject: RE: What is the order of certificates in a certificate chain?

Hi Peter, 

Alex

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
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:

Scenario:

Summary of questions:

Surely, to summarize, 

Peter.

-----Original Message-----
From: Alex Deacon [mailto:[email-masked]]
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?

Alex

-----Original Message-----
From: Christopher Williams [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 8:41 AM
To: PKIX Mailing List
Subject: What is the order of certificates in a certificate chain?

Christopher Williams

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 21 Apr 2000 09:20:32 -0400 (EDT)

Hi Peter,

I believe there is an issue of "best commercial practices"
here.  If a building contractor presented a forged paper license
or misappropriated the identity of a legitimately licensed
contractor, I'm 100% certain that is a misrepresentation of
fact.  If the contractor presented a legitimate license, within
its printed validity interval but which had been suspended/revoked,
a "90% misrepresentation" has occurred.  The homeowner
has a 10% responsibility to check references, the BBB, and the
contractor's professional association, but I suspect a judge
would not penalize the homeowner too severely for not having
done so.

But accepted practice is for police officers to verify the
putative validity of plates and drivers licenses with a radio
call.  And accepted practice for PKIX clients should be to
validate certificates before relying upon them.  If that is
true, there is fault with the CA for misrepresentation, and
fault (at least 50%) with the subscriber for lack of due diligence.
The CA is not blameless, and can be punished (given a black
mark on the compliance audit, or de-certified) by a regulating
body.  But, IMO, the only damages the subscriber suffers is
the fact that subscriber's certificate will not be accepted
by RPs.  The CA is responsible for promises made to deliver
a valid certificate and business lost as a result of failure
to deliver what was promised.  But at the moment of delivery,
(again IMO, IANAL!) the subscriber assumes nearly all the
responsibility for not properly validating the cert as part
of acceptance.

Regards,
Dave

> To: "'David P. Kemp'" <[email-masked]>, [email-masked]
> Date: Thu, 20 Apr 2000 19:57:30 -0700
> 
> Hi David:
>

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 21 Apr 2000 09:34:14 -0400 (EDT)

Agree with all 3.  However, a CPS may require acceptance
actions that are not required by the CMP technical
specification.

If the CPS requires the EE's UA to validate EE's certificate
as a condition of acceptance, the UA will need sufficient
information from some source to perform the validation.
CMP, or PKIX operational protocols, or offline operations
could provide that information.

It's up to an accrediting body, not the IETF, to determine
if all accreditable CPSs must require (2).

Dave

---

From: Carlisle Adams <[email-masked]>
Date: Thu, 27 Apr 2000 17:02:33 -0400

Hi Peter,

> Sent: 	Thursday, April 20, 2000 11:01 PM
 
Agreed.

Note, however, the distinction between the caPubs field in the initRep
message (Section 3.3.2) and the extraCerts field in PKIMessage (Section
3.1).  The initializing EE must receive its trust anchor(s) in some reliable
way.  If this has not happened by some other (out-of-band) means, then the
caPubs field is a convenient and reasonable place to do this.  Certs found
here (in bag order) are intended to be directly trusted as root certificates
and need not be validated prior to acceptance of the newly-issued EE
cert(s).  This implies that they are valid at the moment of creation of this
response message.  It also implies that there is no certificate path here
(there's no reason I can think of to have every CA in a path be a trust
anchor for a given EE).

It is the extraCerts field (again in bag order) that may contain various
"helpful" certs, including (partial) paths.  Such certificates carry no
particular assurance of validity (even at the moment of creation of this
response message) and SHOULD, like all other non-root certificates, be
validated by the EE immediately prior to use.

> paths or CRLs ( or othe status source) at that 
 
Agreed.

The newly-issued certificate may be assumed to be "mechanically valid", by
which I mean that the path from this certificate to the relevant root
certificate is valid according to the mechanical processing rules.  By
accepting the certificate, the EE is telling the CA that the contents of the
newly-issued certificate are acceptable (i.e., validity period is fine;
contained policies are fine; etc., etc.).  The EE need not check signatures,
ARLs for any intermediate CA certs, etc..

> will provide this facility.
 
Agreed.

It is "not clear" because the relevant CMP messages are OPTIONAL (i.e.,
they're not included in the set of messages specified as mandatory for
conformance in Section 4).  These messages, or the PKIX operational protocol
messages, or any other means may be used by the EE to retrieve revocation
information.

Carlisle.

P.S., Good summary of the discussion thus far -- thanks!