David, in May 2008, I had sent you a lengthy report of textual issues I had found in RFC 5280, intended to start discussion with the authors before submitting RFC Errata. The message excluded all less significant editorial nits I had found because of time constraints, and deferred to a later report after resolution of the more significant items. IIRC, in Dublin Russ said "that doesn't hurry"; I also got overwhelmed with other stuff, and I have not pursued the discussion further. The recent postings to PKIX have reminded me of that review and I tried to pick up the response(s) I had received for my message from May 18, 2008 (Subject: RFC 5280) -- however, I could not find any follow-up message(s), I apparently also never have compiled the (deferred) "nits report", and Errata have never been submitted this way. Have these numerous details from my original message been addressed in the version you announced as being posted soon? Some of the items relating to RFC 5280 ASN.1 have been discussed when the ASN.1 got rehashed in the PKIX new-asn1 I-D (must have been in Jan/Feb 2009, as part of my WGLC review of that memo and the ensuing discussion). Also, similar/related suggestions have been discussed for, and a few changes been applied to, the S/MIME 'bis' documents (now at the RFC Editor). I'm not sure whether the mailing list policy admits such long postings, but I attach a copy of the original message for reference and hope it will make it to the list. Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah at TR-Sys.de | +------------------------+--------------------------------------------+
From: Alfred Hönes <ah at TR-Sys.de>
To: david.cooper at nist.gov
Message-Id: <200805182135.XAA12252 at TR-Sys.de>
Date: Sun, 18 May 2008 23:35:40 +0200 (MESZ)
Subject: RFC 5280
Hello,
recently I had been redirected to you as the 'leading' editor
of RFC[-to-be] 5280. Therefore, I initially address this note
only to you; but I expect (and admit) that you might forward it
(or better: parts of it) appropriately and as deemed useful to
discuss the considerations below.
[ Note: Doing so also relieves me from involuntarily having to
exclude form delivery the single co-author I cannot reach per
email because of the inappropriate (DNS) packet filtering still
performed at its affiliation's site, which denies service to
deliver the proper MX records from Redmont to our mail server. ]
After the publication of that RFC, I eventually have urged me
this weekend to take a closer look at that document, and to
pick up deeply buried notices on RFC 3280 I once had made when
I still was much less acquainted with the IETF and this matter.
(1) Section 4.1.2.1
The last paragraph of 4.1.2.1 says:
Generation of version 2 certificates is not expected by
implementations based on this profile.
The RFC is silent about version 1 certificates in this respect.
This is a bit surprising, given the context.
The first paragraph of the same section contains a SHOULD for v2
in its third sentence:
[...]. If no extensions are present, but a UniqueIdentifier
is present, the version SHOULD be 2 (value is 1); however, the
version MAY be 3. [...]
The next sentence similarly deals with another scenario, but issuing
a SHOULD for v1, combined with MAY for v2 and v3:
[...]. If only basic fields are present, the version
SHOULD be 1 (the value is omitted from the certificate as the default
value); however, the version MAY be 2 or 3.
Hence, from that paragraph it could be concluded that this RFC
recommends similar backwards compatibility strategies for the use
of v1 and v2 certificates, whereas the last paragraph unexpectedly
seems to favor v1 over v2 (in the case v3 cannot be used).
This seems to be pretty confusing, in the absence of additional
rationale.
(2) Section 4.1.2.5
It is often said that rarely exercised code is a security risk
in security protocols. Nevertheless, the second paragraph of
4.1.2.5 says:
CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate
validity dates in 2050 or later MUST be encoded as GeneralizedTime.
Conforming applications MUST be able to process validity dates that
are encoded in either UTCTime or GeneralizedTime.
If CAs *MUST* use UTCTime for the foreseeable future, how will
the certificate 'consumer' code for GeneralizedTime be exercised
until 'suddenly', at a certain point in time, CAs start massively
putting GeneralizedTime into certificates? The only relief seems
to be that this point in time still is not very near. :-)
Nevertheless, it might have been preferable to at least weaken the
MUST in the first line above to a SHOULD, from this point of view,
to give applications the opportunity to go through the learning
curve, occasionally exercising GeneralizedTime processing code.
On the other hand, this policy seems to be in strong contrast to
the experiences with Y2K, when everybody, including the IETF,
decided to *always* encode years to 4 decimal digits, whereever
they are used in data processing. Do we really want to forget,
and once learn again, the Y2K lessons? Shouldn't we strongly
accustom programmers, users, administrators, and executives
to never ever see and use 2-digit year numbers again ?
(3) Section 4.2.1.4 -- editorial
The second-to-last paragraph on page 33 says:
vvvv
| If both the noticeRef and explicitText options are included in the
one qualifier and if the application software can locate the notice
text indicated by the noticeRef option, then that text SHOULD be
displayed; otherwise, the explicitText string SHOULD be displayed.
It should perhaps better say:
| If both the noticeRef and explicitText options are included in one
qualifier and if the application software can locate the notice text
indicated by the noticeRef option, then that text SHOULD be
displayed; otherwise, the explicitText string SHOULD be displayed.
(4) Section 4.2.1.6 -- issues with DNS terminology and specification
There are several compatibility issues with DNS buried in the long
paragraph extending from the bottom of page 36 to the top of page 37:
----snip----
When the subjectAltName extension contains a domain name system
| label, the domain name MUST be stored in the dNSName (an IA5String).
^^^^^
The name MUST be in the "preferred name syntax", as specified by
Section 3.5 of [RFC1034] and as modified by Section 2.1 of
[RFC1123]. Note that while uppercase and lowercase letters are
allowed in domain names, no significance is attached to the case. In
| addition, while the string " " is a legal domain name, subjectAltName
| extensions with a dNSName of " " MUST NOT be used. Finally, [...]
----snip----
a) line 2 : As far as I understand the matter the dNSName does not
store a single DNS label -- as does a domainComponent (DC) RDN
(distinguished name component) in the 'subject' --, but instead
a fully qualified domain name (FQDN).
Hence I conclude that "label" is a (legacy) mistake.
b) lines 7 & 8 : Reading RFC 3280, I once thought, '" "' (single space)
for a domain name (Note: not a *label* in this sentence!) would be
a typo, and that the DNS Root, '"."' was meant, I now come to the
conclusion that such interpretation of this unchanged detail also
does not make proper sense.
The references quoted unfortunately are rather vague and ambiguous
(as many other parts of the legacy DNS specifications -- sigh!!),
and Section 2.1 of [RFC1123] actually further refers to the dated
RFC 952 (not even on the Standards Track).
Apparently in an attempt to not disturb the ambiguity in STD 13,
newer RFCs seem to shift back and forth like a hot potato the
responsibility for normative syntax for proper DNS names, but
nowhere could I find an indication that '" "' is a legal domain
name. RFC 952 explicitely excludes SPACE from the set of allowed
characters in a host name, and by means of the established
indistinguability of 'host names' (initially: leave node labels
in the DNS name tree) from other (non-leave node) DNS labels,
this follows for all domain names.
Newer practice has introduced the underscore into domain names
explicitely not intended for *hosts*, but for *services*, e.g.
for labels and subtrees hosting SRV and NAPTR resource records.
The DNS *protocol* in fact does support a much more relaxed
syntax for domain name labels, but the syntax needed in zone
files can become weird and unmanageable, and current ICANN
rules do not allow SPACE in the public DNS name tree.
Taking altogether, there seems to be no point in the rationale
presented in the sentence quoted above.
To avoid confusion, I strongly recommend to address these issues
with an RFC Errata Note. The first one seems simple:
s/label/fully qualified domain name (FQDN)/
but I'm not sure about the proper change for the second issue.
(5) Section 4.2.1.10 -- Name Constraints and Subject Name Semantics
Both excludedSubtrees and permittedSubtrees are OPTIONAL.
The semantics are left unspecified (and are far from being
intuitive) in the case that both are present, nor does this
section specify the logical (or set theoretical) operation
implied by the possible existence of parallel trees for
different name forms.
The 3rd paragraph of 4.2.1.10 only says:
Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees
field is invalid regardless of information appearing in the
permittedSubtrees. [...]
IMHO, this is far underspecified there.
Only by very closely studying the path validation algorithm in
Section 6.1, in particular steps (b) and (c) in Setcion 6.1.3
(on page 80), it becomes clear that
- excludedSubtrees specify exceptions to permittetSubtrees;
- the *intersection* of all permittedSubtrees, not their *union*,
defines the permitted combined namespace, and
- the *union* of the excludedSubtrees defines the exceptions.
The path validation algorithm also has further far-reaching
consequences for the semantics of multiple `subjectAltName's
in the presence of Name Constraints: they are not considered
as alternatives, but as facets of the same name; a certificate
is not accepted if any *one* of the subject [alt] names matches
the constraints, *all* must match the appropriate constraints
for the corresponding form.
Unless I have overlooked material in the text of RFC 5280, these
important aspects are not clearly specified in Section 4.
(6) Section 4.2.1.10 -- another issue
Another issue in the same section appears on mid-page 42.
In Network Management, contemporary terminology found in numerous
IETF defined MIB modules, and, e.g., in proprietary management /
configuration interfaces of routers, precisely distinguishes
between an "address range" and an "address prefix".
An "address range" is specified by a 'first' (lowest numbered)
address and a 'last' (highest numbered) address, independent of
any relationship to the bit pattern in these addresses -- similar
to a "port range" being specified by its minimum and maximum port
number.
In contrast, a (CIDR) "prefix" is specified by a reference address
and a "prefix length" -- equivalent to a left-aligned contiguous
netmask in pre-CIDR parlance; each "prefix" naturally defines a
specific powers-of-two aligned "address range", but the convers
is not true. (Beware that non-contiguous netmasks effectively
had been deprecated by CIDR.)
That said, it becomes apparent that the following text in RFC 5280
can be grossly misleading:
The syntax of iPAddress MUST be as described in Section 4.2.1.6 with
the following additions specifically for name constraints. For IPv4
addresses, the iPAddress field of GeneralName MUST contain eight (8)
octets, encoded in the style of RFC 4632 (CIDR) to represent an
| address range [RFC4632]. For IPv6 addresses, the iPAddress field
^^^^^
MUST contain 32 octets similarly encoded. [...]
By application of the established terminology, it would be concluded
that the "address range" might be encoded in the more general form,
by specifying is first and its last address.
Only the subsequent example makes clear that this interpretation
can not have been intended, and it is not even CIDR notation
(address plus prefix length), but pre-CIDR netmask notation.
For the sake of precision and clarity, I suggest to file an Errata
Note which, at a minimum, replaces the tagged word "range" by "prefix".
(7) Section 5.2.3 -- editorial
The 3rd paragraph of Section 5.2.3 (on page 61) says:
[...] vvvvvvvvv vv
| That is, if the this update field (Section 5.1.2.4) in the two CRLs
are not identical, the CRL numbers MUST be different.
It should say:
[...] vvvv vvv
| That is, if the update fields (Section 5.1.2.4) in the two CRLs are
not identical, the CRL numbers MUST be different.
(8) Section 5.2.4 -- editorial
The second paragraph of Section 5.2.4 (on page 62) says:
vvv
| The delta CRL indicator extension contains the single value of type
BaseCRLNumber. [...]
It should say:
v
| The delta CRL indicator extension contains a single value of type
BaseCRLNumber. [...]
(9) Section 5.2.6 -- clarification/editorial
The first paragraph of Section 5.2.6 (on top of page 67) says:
The freshest CRL extension identifies how delta CRL information for
| this complete CRL is obtained. Conforming CRL issuers MUST mark this
^^
extension as non-critical. This extension MUST NOT appear in delta
CRLs.
It should better and more precisely say:
The freshest CRL extension identifies how delta CRL information for
| this complete CRL can be obtained. Conforming CRL issuers MUST mark
^^^^^^
this extension as non-critical. This extension MUST NOT appear in
delta CRLs.
(10) Section 6.1.6 -- clarification/editorial
On page 89, Section 6.1.6 says:
If path processing succeeds, the procedure terminates, returning a
| success indication together with final value of the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
valid_policy_tree, the working_public_key, the
working_public_key_algorithm, and the working_public_key_parameters.
It should say:
If path processing succeeds, the procedure terminates, returning a
| success indication together with the final values of the
^^^^ ^
valid_policy_tree, the working_public_key, the
working_public_key_algorithm, and the working_public_key_parameters.
(11) Appendix A.
It is not clear from the RFC text, why it is necessary to split
the ASN.1 into two complementary modules.
(Even more, the fact that they are complementary, not alternative,
is also not stated in the text and needs to be figured out.)
Although the first one in A.1 sets EXPLICIT as the tagging default,
almost all tagged elements in that module contain the keywords
IMPLICIT or EXPLICIT.
Apparently, with only a few more additions of such keywords, the
module default could have been changed to the general ASN.1 default,
IMPLICIT, opening the opportunity to join the two modules and
present a single one in a uniform definition style.
I guess that all this stuff simply has to do with legacy and
the intent to not perform otherwise reasonable changes for the
sake of textual proximity to the previous document.
I would have strongly appreciated if the rationale for the module
split would have been explained in similar detail as the string
syntax mess, in the introductory text in Appendix A.
This would have saved quite some time needed to figure out the
facts (hopefully correctly) as stated above.
(12) A.1, page 111
The ASN.1 comment at the bottom of page 111 looks like borrowed
from a 'new' ASN.1 version of the module and not retrofitted
completely to 1988 parlance.
-- suggested naming attributes: Definition of the following
vvvvvvvvvvvvvvvvvvvvvv ^^^^^^^^^^^^^
| -- information object set may be augmented to meet local
-- requirements. Note that deleting members of the set may
-- prevent interoperability with conforming implementations.
The concept of "information object set" does not exist in X.280,
and it is not formally represented on the subsequent pages in 1988
ASN.1. Thus, this RFC text is a bit confusing.
(13) A.1, pages 115 vs. 119 -- SIZE parametrization
On mid-page 115, the ASN.1 module says:
X520countryName ::= PrintableString (SIZE (2))
All other instances of object syntax for ISO 3166.1 country codes in
this module make use of the parameter `ub-country-name-alpha-lenght`
defined on page 124, e.g. on mid-page 119:
iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) }
Is the above "SIZE (2)" an oversight,
or are there specific reasons to not make use of the
existing (and obviously applicable) parameter ?
(14) Appendix B -- outdated text
The last paragraph on page 135 says:
[...]. For example, at least two extension
| definitions included in [RFC2459], the predecessor to this profile
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
document, have different ASN.1 definitions in this specification, but
the same OID is used. [...]
Apparently, this text has inadvertently not been transformed to
the context of this third edition of the profile.
The RFC should state:
[...]. For example, at least two extension
| definitions included in [RFC2459], the first version of this profile
^^^^^^^^^^^^^^^^
document, have different ASN.1 definitions in this specification, but
the same OID is used. [...]
(15) Appendix C.
For the exploration of the details involved in item (4) above,
it would have been appreciated very much to find in Appendix C
example material showing the use of the dNSName variant of
subjectAltName.
(16) further nits [omitted]
For the sake of brevity and to save time, I have omitted from this
note all the minor editorials I've been stumbling over, e.g.,
missing or inappropriate articles, and similar editorial details.
I'll make these available on request -- soon or any moment of time
in the foreseeable future you like; all is filed on persistent data
storage media: paper printout with pencil-written side notes. :-)
[But please admit significant processing time for such low-priority
task.]
After reconsideration, it might be deemed useful to address some
of the items above in appropriate RFC Errata Notes, as already
indicated in part above. If you prefer to do that yourself,
please also freely make use of suitable material presented above.
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah at TR-Sys.de |
+------------------------+--------------------------------------------+
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.