Subject: [sidr] comments on draft-ietf-sidr-repos-struct-03.txt

From: Sandra Murphy <[email-masked]>
Date: Wed, 2 Dec 2009 20:20:52 -0500 (Eastern Standard Time)

The following are not points that anyone else raised.  I decided that I 
should raise them as working group member, NOT as working group chair.

Comments on draft-ietf-sidr-repos-struct-03.txt.

(1) Entry and removal from a publication point

I noticed that the document frequently makes mention of manifest's listing 
of all objects produced by a CA.  (e.g., "The manifest contains a list of 
the names of all objects issued by that CA or signed by the EE certificate 
and published in a repository publication point directory,")  That is not 
actually true, if I understand manifests correctly.  The manifest lists 
all objects in the publication point, which means the current, unrevoked 
objects.  Right?

I thought "current, unrevoked" ought to be added to each such mention of 
the manifest.

This raised the question that the document says that it describes the 
content of the structure, but it never says when content is added or 
removed.

I checked, and the manifest does not seem to cover this either.  It says
                                        "The manifest's fileList includes
        the file names and hash pair for all objects associated with this
        CA that have been published at the CA's repository publication
        point."
and
      o  An authority MUST issue a new manifest in conjunction with the
       finalization of changes made to objects in the publication point.

which pushes the question off to the description of what is in the 
publication point.

Perhaps it would be good to add the following statement:

Objects are added to the repository structure when issued or signed, and 
are removed when expired or revoked.

IF, of course, that is true.

Is it?  Is it so completely obvious that it does not need to be mentioned?

Note that the manifest document also says

       An authority MAY perform a number of object operations on a
       publication repository within the scope of a repository change
       before issuing a single manifest that covers all the operations
       within the scope of this change.  Repository operators SHOULD
       implement some form of synchronization function on the repository
       to ensure that relying parties who are performing retrieval
       operations on the repository are not exposed to intermediate
       states during changes to the repository and the associated
       manifest.

which seems like it deals also with the repository publication point 
content and would be good to include in the repository structure document.

(I actually think things would still work if expired or revoked objects 
were left lying around in the repository, as long as the manifest checking 
raised no alarm for seeing them there.  That's not hygenic, of course.)

(2) Language regarding signing

It is common to say say "the certificate signed this <object>".  That's 
not actually correct, and saying it in full glory means saying things like 
"objects signed using the private key associated with the public key 
certified in the certificate".

The draft goes through the tortuously precise language twice (page 4 "all 
objects signed by the private key part of the key pair whose public key 
part is the subject of this certificate" and page 8 "the EE certificate 
that has certified the key pair that as used to sign the object") and uses 
the common language many times ("or signed by the EE certificate", "all 
objects that are signed using a "single-use" EE certificate", "that points 
to the the repository publication point of the objects signed by this EE 
certificate", etc.)

I don't think the full rigor is needed everywhere.  I'd recommend putting 
that language near the beginning and say something like "from now on, when 
we will use the inaccurate but shorter statement "the certificate signed 
the object" to mean this signing action.

(3) Language

About the language in the introduction:

    A Resource Certificate describes an action by an Issuer that binds a
    list of IP address blocks and AS numbers to the Subject of a
    certificate, identified by the unique association of the Subject's
    private key with the public key contained in the Resource
    Certificate.

Someone else remarked about this language.  This is used in the rescerts 
document as well.  I admit that I've always thought it rather convoluted 
and maybe not even accurate.  Does a certificate embody the action of 
binding or does it accomplish the binding by its existence?  and such 
philosophical pronouncements.  However, I don't think the language here 
hinders the document to the point that it must be changed.

(4) Directories and publication points

The repository structure for the most part talks about "publication 
points", but in section 3 it starts talking about publication directories 
and subdirectories.

Subdirectories are to be publication points for CAs that are contained in 
the directory.  I found it difficult to maintain separation between the 
ideas sof a publication point and a directory - the most common case will 
be when the publication point is a file system directory, obviously.  But 
does the publication point naming system have anything to do with the file 
system directory naming structure?  Do the naming guidelines only propose 
a name for the last component of a hierarchical file system name, which 
one presumes is the directory name?  Does the restriction on subdirectory 
contents in a publication point directory have anything to do with the 
required content of a publication point.  (I.e., the objects listed in the 
manifest are all objects in the publication point, but we don't need to 
say "except for subdirectories" because the manifest objects are those in 
the abstract "publication point", not the file sytsem directory that hosts 
the abstract publication point.  Is that anywhere near correct?

Are directories and publication points synomonous?

Is the "file system directory" part of the following statement exactly 
true?

    For every certificate in the PKI, there will be a corresponding
    repository publication point file system directory

Should the following say "directory" or "publication point"

                                                                That
    is, if the subject of certificate A has issued certificate B, then
    the AIA extension of certificate B points to certificate A, and the
    SIA extension of certificate A points to a directory containing
    certificate B (see Figure 1).

And so forth.

    o  Each CA publication directory in the publication repository should
       contain the products of this CA, including those objects signed by
       single-use EE certificates that have been issued by this CA.

Since a directory might host products from multiple CAs, what is this 
trying to say?

(5) Access method

Sometimes the text talks about "access method" and sometimes 
"accessMethod".  The rescerts document says "access mechanism" when it is 
not talking about the "accessMethod".  I wasn't sure if "access method" 
should have been "accessMethod", and if not, then maybe "access mechanism" 
would remove the ambiguity.

(6) Suggested naming scheme

The discussion on page 6 says that CRLs and namifest both use the 4387 
algorithm to dervive the name from the public key hash to a string. 
Obviously they can't both have the same name - is there some required 
suffix or extension that would distinguish them?  (section 2.3 on page 7 
talks about objects with a common "base name element" - probably the same 
term could be used here)

(7) MUST and SHOULD

This document uses "MUST" and "SHOULD" at times, and "must" and "should" 
at times.  I was not sure if the lower case was meant to be upper case. 
Seems particularly a problem in section 4:

    If a CA certificate is reissued, it should not be necessary to
    reissue all certificates signed by the certificate being reissued.
    Therefore, a CA SHOULD use a persistent naming scheme for the
    certificates's repository publication point that is persistent across
    certificate reissuance events.  That is, reissued certificates should
    use the same repository publication point as previously issued
    certificates having the same subject and subject public key, and
    should overwrite previously issued certificates within the repository
    publication point directory.

Some of those uses of "should" seem to be normative.

(8) Synchronizing repositories

I wonder how the top down walk from trust anchors will work in Steve 
Kent's scheme in which the local trust anchor re-issues some certs to 
restrict authority - will the walk of the repository system still work? 
(I can't claim that I have full understanding of Steve Kent's proposal, so 
this could be really off-base.)

(9) Nits

I have not checked other people's nit lists to see if the following is 
duplicative.

is "complete set" -> is a "complete set"
Becuase -> Because
the entity may chose to continue of use -> the entity may choose to 
continue the use
pooint -> point
Whn multiple CA's -> When multiple CA's
using RSYNC [rsync][I-D.sidr-res-certs] Support -> missing the period
the SIA of the associated CA or EE -> the SIA of the associated CA or EE 
certificate
of related CA's -> of related CAs
the the local repository cache will -> the local repository cache with

--Sandy