RE:Pointer to X.509 FPDAM and defect report documents

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

Here is the pointer to the FPDAM. You'll only find approved and published
documents on 
the ITU site. This one is currently out for ISO ballot and still under ITU
study. The 
Annex M Santosh refers to is in this document. 

Hoyt Kesterson was planning to send a message to the PKIX list alerting to
the fact that
the FPDAM is under ballot, hoping that PKIX review will result in an IETF
ballot response 
containing a consolidated set of comments on the FPDAM. Hoyt is on vacation
and has also 
had some computer hardware problems, so I'm not sure if he sent the message
or not.

Here's the reference to the FPDAM text:

ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

Also here is a pointer to the outstanding defect reports against X.509:
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509/

and to the resolutions for those defects, also currently (I believe) out for
ballot
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigend
a/X.509/

I haven't checked each defect document to make sure they're all there, but I
believe they are.

An IETF PKIX response to the DTC ballots can also be submitted.

Sharon 

-----Original Message-----
From: Khaja E. Ahmed [mailto:khajaa@valicert.com]
Sent: Thursday, July 22, 1999 7:55 PM
To: 'Santosh Chokhani'; 'Sean Turner'; 'PKIX'
Subject: RE: CRL Checking Text


Santosh,

The only X.509 recommendation I am able to find on the ITU web site is the
08/97 version which does not have Annex M.  Can you send the Annex or the
pointer to this group so we can review it.  Thanks.

Khaja


-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
Sent: Thursday, July 22, 1999 2:56 PM
To: 'Sean Turner'; PKIX
Subject: RE: CRL Checking Text


We have done detailed work on this topic and Annex M of the latest X.509
FPDAM has the pertinent language/rules.  I think PKIX should start with
Annex M and revise it if and only if necessary.

> -----Original Message-----
> From:	Sean Turner [SMTP:turners@ieca.com]
> Sent:	Thursday, July 22, 1999 5:45 PM
> To:	PKIX
> Subject:	CRL Checking Text
>
> All,
>
> I asked a few weeks ago where the explicit requirements were to
> check/verify CRLs in RFC 2459.  The is some text in section 6.1 that
> says:
>
>          Verify ... the certificate had not been revoked at time T and
> is not
>          currently on hold status that commenced before time T, (this
>          may be determined by obtaining the appropriate CRL or status
>          information, or by out-of-band mechanisms),
>
> I think we need a little more information that explicitly states what
> the verification steps are for CRLs.  Attached is some suggested text:
>
> Prior to trusting an issuer's CRL, the signature across the CRL must
> itself be validated.  When required to validate a CRL during
> certificate
> path verification, CRL verification requires the following checks:
>
> 1. Verify the signature on the CRL, distribution point CRL, or delta
> CRL
> by employing the public key from the CRL issuer's certificate. If the
> signature across the CRL is invalid, the user shall be notified that
> the
> signature was invalid and instructed to obtain a new CRL from the
> repository. If a valid CRL cannot be obtained, then the user will be
> given the option to proceed without a valid CRL and without using the
> invalid CRL.
>
> 2. Verify the certification path (see clause 6 of RFC2459) of the CRL
> issuer's signature certificate.
>
> 3. Verify that the present time, T, falls between thisUpdate and
> nextUpdate.  If time T is later than the nextUpdate value, the user
> shall receive guidance to obtain a later CRL from the repository, and
> be
> given the option to proceed with the out-of-date CRL (signature must
> still be checked).
>
> 4. Verify that the cRLNumber is greater than that of the last CRL that
> the user possesses.
>
> 5. Verify that the name in the CRL's issuer field or the
> certificateIssuer extension is the issuer of the certificate.
>
> 6. If the keyUsage extension is present in the CRL issuer's
> certificate
> and is flagged critical, verify that the cRLSign bit is set to 1.
>
> 7. Check whether the certificate's serialNumber appears on the CRL,
> distribution point CRL, or delta CRL.  If the certificate's serial
> number is present, and if no reasonCode exists, or a reasonCode exists
> and is either unspecified, affiliationChanged, superseded, or
> cessationOfOperation, notify the user of which certificate is on the
> CRL, distribution point CRL, or delta CRL and allow the option to
> proceed with data processing.  If the reasonCode is keyCompromise or
> certificateHold, the user shall be notified and the certificate shall
> be
> rejected thereby halting all associated processing.  If a certificate
> that appears on the CRL, distribution point CRL, or delta CRL is a CA
> certificate, regardless of the reasonCode, the user shall be notified
> and the certificate shall be rejected thereby halting all associated
> processing.  If the revoked certificate is the user's certificate, the
> user will be directed to notify the associated CA.
>
> The notification returned to the user at the end of the CRL check
> shall
> at a minimum shall:
>
> - List all expired certificates in the certificate chain.
>
> - Explicitly state that the certificate(s) is/are expired.
>
> - Explicitly state that the certificate(s) may have been revoked, and
> that the certificate will not appear on current CRLs even if the
> certificate has been revoked.
>
> - Explicitly state that the signature applied to the entity being
> verified may not be valid. Verification of signatures using expired
> certificates requires the assistance of the originator's CA.
>
> - Require positive user action to acknowledge the warning message
> (i.e.
> clicking an on-screen OK button) before data processing
> continues.
>
> Thoughts?  Too restrictive or not enough info?
>
> spt