Re: Last Call: Internet X.509 Public Key Infrastructure Certificate and CRL Profile to Proposed Standard

> Date: Fri, 07 Aug 1998 08:39:28 -0400
 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) Working Group to consider Internet X.509 Public Key
> Infrastructure Certificate and CRL Profile
> <draft-ietf-pkix-ipki-part1-09.txt> as a Proposed Standard.
 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by August 21, 1998.

During the last call period at the WG level I posted several comments.
Some of them generated much trafic and a rough consensus has been
reached on them. Coming back from holidays I checked draft-09 (posted
after July 29) against my initial list and the following is still a
concern:


1. About section 4.2.1.11 I said that the current text was not clear
enough to understand the overall model. Many modifications have been
made to the text. However no text is still lacking to explain the ASN1
syntax:

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

I could pick up X.509 and certainly get some explanations, but one
purpose of this specification is to avoid this. Some additional text
would certainly be appropriate here.(BTW, in the fifth paragraph, change
"Internat" into "Internet").


2. My major comment previoulsy numbered E was about a new conforming
clause on key identifiers on page 24. Section 4.2. The text from the
draft 8 is :

   Conforming CAs are required to support key identifiers (see sec.
   4.2.1.1 and 4.2.1.2), basic constraints (see sec. 4.2.1.10), key
   usage (see sec. 4.2.1.3), and certificate policies (see sec. 4.2.1.5)
   extensions. 

The text from the draft 7 was:

   Conforming CAs are required to support the basic Constraints exten-
   sion (Section 4.2.1.10), the key usage extension (4.2.1.3) and certi-
   ficate policies extension (4.2.1.5). 

Although key identifiers may be useful, no rational has been given to
say why they shall be mandated (and thus overload the certificate
contents). I would accept to have them mandated if some explanation is
given and incorporated into the text ... otherwise I will be wondering
for ever the right reason to mandate them. :-)


3. The minor comment previoulsy numbered 4 has been incorporated in the
text in principle but not the minor comment 1 which deals with the same
topic. I would suggest that we perform a similar change (i.e. add "and
other assured information ").

Current text (page 10. section 3.2):

                        If the public-key user does not already hold an
   assured copy of the public key of the CA that signed the certificate,
   then it might need an additional certificate to obtain that public
   key. 

New proposed text:

   If the public-key user does not already hold an assured copy of the 
   public key and other assured information of the CA that signed the 
   certificate, then it might need an additional certificate to obtain 
   that public key. 


4. My next concern is about the last minor comment, previously numbered
10. On page 50, section 6.1., the current text states:

   The text assumes that the trusted public key (and related informa-
   tion) is contained in a "self-signed" certificate. 

It would be appropriate to explicitly recall that the information may
also come by out-of-bands means and does not only include the public
key. The following is proposed as a clarification:

" The text assumes that the trusted public key of the CA, the CA's name,
the validity period of the public key, and any constraints upon the set
of paths has been obtained from a "self-signed" certificate. However the
same information may also be available using out-of-bands means."

I see two good reasons to clarify the text:

1) Many people are ommitting or wondering what is the "related
information".
2) That "related information" may or may not be in a self-signed
certificate.


5. The text in section 3.1. states:

   Users of a public key must be confident that the associated private
   key is owned by the correct remote subject (person or system) with
   which an encryption or digital signature mechanism will be used.

We have had a long thread about proof-of-possession for DH keys. This
thread stopped shortly after Mike Smith said:

"POP and all other operational requirements or best practices should be
in the policies and concept of operations efforts and so should be the
debate". 

Stephan Santesson also said: 

"But the decision to mandate POP for a specific set of certificates can
only be made by the CA and should then reflect the identified
certificate policy where this requirement should be specified."

I initially wanted a rollback to the previous text which was:

   Application of public key technology requires the user of a public
   key to be confident that the public key belongs to the correct remote
   subject (person or system) with which an encryption or digital signa-
   ture mechanism will be used.

I could live with the current text as long as it is clearly understood
within the group that this sentence does not in any way mandate POP,
i.e. the confidence may be obtained either because the subject asserted
to the CA that he had the corresponding private key or because the CA
made sure that the user had (or was given) at the time of registration
the corresponding private key. 

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:Denis.Pinkas@xxxxxxxx
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21