Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

From: Peter Williams <[email-masked]>
Date: Wed, 24 Apr 2002 18:51:06 -0700

Mike,

(1) Can you provide a citation or other professional
reference for the "precise technical meanings" of "valid" and
"invalid", please?

(2) Could you also perhaps help me compare
the definition(s) of "valid" used in the 
VeriSign CPs (1.2 and 2.0)and the US DOD CP v2 (March 
1999), perhaps, against the recognised
definition of "valid" (see above (1))?

In my reading, the two policies seem
to offer very different notions of validity:

(a1) VeriSign CPS 1.2 (that was effective during issuing of 
many intermediate CA certs:)

"CERTIFICATE MANAGEMENT
Certificate management includes, but is not limited to storage, 
dissemination, publication, revocation, and suspension of certificates. 
An IA undertakes certificate management functions by serving as a 
registration authority for subscriber certificates. An IA designates 
issued and accepted certificates as valid by publication.

VALID CERTIFICATE
A certificate issued by an IA and accepted by the subscriber listed in it.

VALIDATE A CERTIFICATE (i.e., of an END-USER SUBSCRIBER CERTIFICATE) 
The process performed by a recipient or relying party to confirm that 
an end-user subscriber certificate is valid and was operational at the 
date and time a pertinent digital signature was created.

VALIDATE A CERTIFICATE CHAIN 
For each certificate in a chain, the process performed by the recipient 
or relying party to authenticate the public key (in each certificate),
confirm 
that each certificate is valid, was issued within the operational period of 
the corresponding IA certificate, and that all parties (IAs, end-user 
subscribers, recipients, and relying parties) have operated in accordance 
with this CPS as to all certificates in the chain."

(a2) CPS 2.0 - currently effective:

This CPS avoids use of the term valid (in respect of certificate)
altogether:

"Relying Party Agreements also require Relying Parties to check the 
status of a Certificate on which they wish to rely, as well as all the 
Certificates in its Certificate Chain in accordance with CPS ?? 4.4.10, 
4.4.12.  If any of the Certificates in the Certificate Chain have been 
revoked, according to Relying Party Agreements, the Relying Party must 
not rely on the end-user Subscriber Certificate or other revoked Certificate
in the Certificate Chain. 

(b) DoD CP v2.0

"2.1.4	Relying party obligations

check each certificate for validity, using procedures described in the X.509

standard, and prior to reliance."

"The authorized source for information concerning the 
validity of a certificate shall be the revocation mechanism 
provided by the CA as defined in its CPS."

But note that validity is fungible in DoD CP (and a DOD
validation policy by construction)

"CA termination will be handled in accordance with section 4.8 
above. If the termination is for convenience, contract expiration, 
re-organization, or other non-security related reason, then 
certificates may continue to be considered valid at the 
discretion of the program or relying party (who has been made 
aware of the termination)."

>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[email-masked]]
>>>>Sent: Wednesday, April 24, 2002 5:44 PM
>>>>To: Trevor Freeman; PKIX
>>>>Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>>>>
>>>>
>>>>
>>>>Trevor,
>>>>
>>>>No, what I'm saying is that valid and invalid have precise
>>>>technical meanings that could be potentially relevant to an
>>>>arbitration panel if not a court of law.

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 24 Apr 2002 19:47:39 -0700

Peter,

See below.

Mike

> From: Peter Williams [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 6:51 PM
> To: 'Michael Myers'; PKIX

Which of the following do you believe should be eliminated from
such a definition:

1. Formation of a valid path IAW 2459;

2. Confirmation of revocation status for each
   certificate in said path;

3. Cryptographic validation of said path IAW 2459.

4. Other practices as required by policy.

> definition of "valid" (see above (1))?

Nope.  Go for it.

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 25 Apr 2002 09:57:56 -0400

Mike:

I think that RFC 2459 (and soon RFC 3280) clearly define a valid 
certification path.

Anything that does not meet this definition is invalid, regardless of the 
reason.

Russ