Here are some early comments on the 1114E draft, based on a first pass through
it. I hope and believe that we'll be able to make significant progress in San
Diego towards stabilizing, progressing, and promulgating the set of PEM specs.
The paragraph ending page 6 states that "... every CA must be certified by a
PCA..." I think it would be better to state that "every CA's certification
path can be traced to a PCA, through zero or more intermediate CAs", or words
to that effect, to avoid a connotation that all CAs must be directly certified
by their PCAs.
On page 8, sec. 3.3.2, I can't help suspecting that we'll run into eventual
compatibility problems by specifying a maximum length for the integer
certificate serial numbers used for PEM purposes, particularly if CA
implementations or workshop agreements emerge using or specifying a larger
number. Do the NIST OIW agreements constrain the size of this element?
On page 13, section 3.4.1.3, first paragraph, it's stated that the UA
certificate cache provides a basis for improved performance. More centrally, I
believe, it makes it possible for PEM UAs to operate at all in the absence of
available and connected directories; as such, its function is significantly
broader than a performance optimization.
Page 14, 3.4.1.4, first paragraph, suggests an ambiguity that could cause
interoperability problems. It recommends that an originator should include
Issuer-Certificates in the absence of ubiquitous directories or knowledge that
a recipient already possesses those certificates. The ambiguity revolves
around what constitutes a basis for the requisite "knowledge". It's reasonable
to assume that a recipient will retain the set of certificates extending from
the recipient up to the ICA. In contrast, if I sent you a certificate-bearing
message six months ago and we haven't communicated since, it may not
necessarily be reasonable for me to assume that your cache still retains the
certificates (extending from me to our common ancestor) which were sent in that
message, An originator can't be assumed to track the management procedures
applied to a recipient's cache, and the caches may not be able to grow without
bound at all UAs. The safe (though bit-inefficient) course is to send the
Issuer-Certificate chain in all cases; no means are architected within PEM to
determine whether the transmitted chain will or will not be redundant, or to
enable a recipient to acquire automatically from an originator needed
certificates which were not originally transferred. I'm not quite sure,
however, just how (or whether) to change the text so as to strengthen the
guidance to implementors. Perhaps a useful qualification would be "knowledge
(acquired through out-of-band means)"?
Page 14, 3.4.1.4, later in first paragraph: states that "When an originator
submits an ENCRYPTED message ... his UA must validate the certificates of the
recipients..." Cached indications that those certificates have been
successfully validated and remain current and un-revoked seem like functionally
equivalent local alternatives to revalidating the certificates directly, and
shouldn't be precluded.
p. 18-19, 3.4.2.5: there's an apparent inconsistency between the first two
paragraphs. The first states, "The frequency of issue of CRLs may vary
according to PCA-specific policy", which seems right. The second paragraph
states, however, that "Each PCA will maintain a CRL for all of the CAs which it
certifies and these CRLs will be updated biweekly", which suggests that all
PCAs' policies must specify the same (biweekly) frequency.
p. 28, first para, refers to "User-Certificate:" field. This should be
"Originator-Certificate:".
p. 30-31, paragraph spanning page: States that subject DN of every certificate
must be subordinate to the certificate issuer DN, except if the issuer is a
PCA. Doesn't the same exception also apply to certificates (of PCAs) signed by
the ICA itself?
--jl