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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
