Subject: Summary from April X.509 meeting

From: Sharon Boeyen <[email-masked]>
Date: Fri, 30 Apr 1999 12:41:37 -0400

As you know, the meeting that resolved ballot comments on the PDAM to X.509
was held a couple of weeks ago. I'm still making the final revisions to the
text, based on meeting participant feedback to my drafts. The final text
that will be sent out for FPDAM (Final Proposed Draft Amendment) will be
available mid - late next week. In an effort to improve the flow of
communication between the X.509 group and other groups interested in that
work, I'm sending this as an INFORMAL summary of some of the changes to the
PDAM resulting from that meeting. Because the document is still under review
by attendees it is possible that the end result may differ slightly from the
way I've recorded here, but I think these are fairly representative
(editorial and other minor changes excluded).

Also, at the end I'll provide a summary of the defect reports currently
against X.509. I'm hoping to have the formal defect reports and the formal
Draft Technical Corrigenda (DTC) for all of these also available within a
week. You will notice that some of these defect reports are very old and
resolutions were agreed two years ago. However, some have not yet been
formally balloted as DTCs yet. 

ISO ballots on the FPDAM and on all DTCs for outstanding defect reports are
expected to be conducted over the summer months and resolution of those
ballots is expected to occur in October. 

When the documents have been completed and are available on a server, I'll
post a notice indicating where they can be found. 

------------------------------------------------------
FPDAM major changes:
1. X.509 will be re-titled "Public-Key and Attribute Certificate
Frameworks". It will be re-structured into 4 major sections: i) General
Introduction ii) Public-key certificate framework iii) Attribute certificate
framework iv) Directory use of public-key and attribute certificate
frameworks. Annex B will be deleted. 

2. CRLs - Clarified a number of issues relevant to 97 delta CRLs:
    - cert placed on hold and subsequently released (both on deltas) -
nothing need be carried forward to new base
    - cert revoked on delta and expires prior to issuance of new base -
revocation gets carried forward to new base
    - base crl pointed to be delta crl must be complete for given scope (ie
can be a full and complete CRL, distribution pt CRL etc)
   New enhancements in the area of delta CRLs
    - can issue delta CRLs for a base that was not published as a CRL
complete for scope  ('virtual' complete for scope CRL would be locally
constructed from published CRLs)
    - can identify base crl by its update time and/or crl number
    - new 'stream identifier' extension to enable unique identification of a
CRL among all CRLs issued by a particular issuer
   General CRL handling 
    - Annex M updated to align with new agreements and new extensions
including:
         - if basicConstraints extension is absent in a v3 cert it is an
end-entity cert (previously was type unknown)
         - no special case situation for ca or key compromise reason codes -
relying party checks crls for reason codes of interest - dependent on policy
   - Clarified text to state that revocation may be done directly by the
authority that issued the certs, indirectly by an authorized entity, or not
at all. Also clarified that CRLs are one mechanism but others are possible
(however they are outside the scope of 509)
(You'll find most of these changes reflected in the crlScope extension and
its description, revised description of deltaCRLIndicator extension, new
clause 12.6.4, revised annex M and new annex O) 
   
3. The syntax for privilegePolicy will not be standardized. Rather
privilegepolicy can be identified by an OID. The syntax from the PDAM and
corresponding SPIF syntax will both be included in an information annex
(Annex N) as examples only.

4. New certificate extensions defined (some of these are for privilege
management others are related to public-key certs in the 'traditional'
sense):
- delegator attribute identifier
- CRL stream identifier
- indirect issuer
- user notice
- SOA identifier
- base update time
- acceptable cert policies

5. New object class defined:
-  CP CPS

6. New attributes defined:
- attribute descriptor certificate
- certification practice statement
- certificate policy

7. New matching rules defined:
- owner issuer match
- authority ID match
- indirect issuer match
- delegator attribute id match
- owner attribute id match
- basic att constraints match
- attribute name constraints match
- time spec match
- attribute descriptor match
- acceptable cert policies match
- SOA id match

8. Assigned an oid to the special value "any policy" to be used in certs
issued from one CA to another CA.

9. Raised an issue regarding duplicate names and how to handle this problem
(mapping internal to external names raised in the issue to help generate
input)

10. Attribute certificate syntax - for v2 attribute certs owner and issuer
changed from CHOICE to SEQUENCE and constructs moved from inline to separate
constructs. Although in most cases a claimant will present both their
attribute cert and their public key cert that authenticates them, for those
cases where both are not provided, this change allows an attribute cert to
point to a public-key cert but also include general names that could help a
verifier find the public key cert in a repository.

11. Delegation path validation text re-written to accommodate new extensions
and provide a more comprehensive description of the role the extensions play
in the path validation.

---------------------------------------------------------
Defect reports - for ALL of these, resolutions have been agreed (either at
previous meetings or at this one) and will be documented as DTCs for ballot
shortly, or have already completed and are formally approved: (DR ## is the
Defect Report number, TC means completed ballot and formally approved, DTC
means approved for ballot). I'm only listing those against the 97 edition

DR 169  permutable property for PKCS  DTC 2
DR 183  public key usage                    TC 1
DR 184  certification path                     Rejected - no change
DR 185  forward & reverse certificates   DTC 4 
DR 200  crl dp & full crls                      DTC 3
DR 201  issuing dist pt                        DTC 3
DR 204  crl and expired revoked cert    DTC 5
DR 207  algorithm object class            DTC 6
DR 212  crl matching rules                  DTC 3
DR 213  crl matching rules                  DTC 3
DR 214  use of term 'canonical'            DTC 6
DR 216  certificate assertion                Rejected - no change
DR 218  certificate policy match           DTC 3
DR 219  absence of basic constraints   DTC 3
DR 220  crl version number                   DTC 3
DR 222  policy mapping                       DTC 7

On DR 219 and 220, I know these are of particular interest to PKIX. I
haven't written 
the formal documents yet, but to summarize:

DR 219 - the resolution agreed for ballot is that for a version 3
certificate, if the certificate does not contain a basicConstraints
extension, the certificate is to be considered an end-entity certificate. We
decided that the goal can be achieved with this resolution and that we won't
unnecessarily force the 'fattening' of ALL v3 certs by mandating the
extension always be present (we see that as the role of profiles).

DR 220 - In the list of notes following the ASN.1 in clause 11.2, note 3
will be modified so that rather than mandating that the version component
"shall" be absent if a CRL contains no critical extensions, the version
component "may" be absent....

Apologies for the length of this message, but I hope the information is
helpful to people who did not attend the 509 meeting when reviewing its
output. Also, I've most certainly forgotten some other technical changes
that were made so if something isn't listed here it isn't that I don't think
it was important, but that the memory is fading........

Sharon