[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Part1 last call comments
All of these comments deal with the ASN.1 modules in
draft-ietf-pkix-new-part1-04.txt and
draft-ietf-pkix-ipki-pkalgs-01.txt. Jim Schaad posted some comments
earlier, but I do not completely agree with his resolutions. I will
address those second. First, I want to raise a two things that were not
raised in Jim's message.
1. AuthorityKeyIdentifier is defined as:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
There is nothing wrong with this ASN.1; however, at least one compiler
wants either "EXPLICIT" or "IMPLICIT" to be inserted before
CertificateSerialNumber. Obviously, only one of these is correct. The
problem in the compiler seems to come from the fact that
CertificateSerialNumber is imported from the explicit module.
The same compiler would like "EXPLICIT" or "IMPLICIT" to be inserted before
uses of ORAddress, Name, DirectoryString, and RelativeDistinguishedName.
A programmer must know a fair amount about ASN.1 to know the correct type
of tagging in each case. To avoid implementation errors from anyone that
might use that tool, should we make the insertion? My initial reaction is
that anyone who uses a tool with such shortcomings must edit the module to
overcome them. I think that preserving alignment with X.509 is
important. However, I think we should make sure that the example
certificate includes these cases to help implementors catch mistakes early
in the development process.
2. The implicit module (section A.2) contains the following:
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
IssuingDistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE }
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
This matches the definitions from X.509 (4th Edition), but it is still a
very strange use of CHOICE. It relies on a little-known ASN.1 rule:
The tagging construct specifies explicit tagging if the "Tag Type"
alternative is used and the value of "TagDefault" for the module is
"IMPLICIT TAGS", but the type defined by "Type" is a choice type
or an any type.
The same compiler as discussed above, does not internally implement this
rule. The programmer must insert the "EXPLICIT." Again, my reaction is
that anyone who uses a tool with such shortcomings must edit the module to
overcome them. I think we should make sure that the example certificate
includes these cases to help implementors catch mistakes early in the
development process.
I think that implementors would be well served if the specification
included the binary certificates were made available. I do not think that
we should make the document any bigger. Perhaps we can develop a companion
document that contains several sample certification paths with CRLs to aid
developers. Of course, we need to carefully consider the validity periods
for the sample certificates to be useful to future developers, but that is
a topic for another thread.
Now to Jim Schaad's message.
3. Section 4.2.2.2 - Recommend moving the defintion of id-ad-caRepository
to implicit ASN.1 module since that is where accessLocation is located.
Good idea. I do not think that moving the OID definition will impact
anyone that already did an implementation.
5. ASN Module A.1: Do not have a new module OID for this.
A new OID for the modules was assigned quite some time ago. It should have
been included in this draft.
id-mod-pkix1-explicit OBJECT IDENTIFIER ::= { id-mod 18 }
6. A.1:
X520SerialNumber PrintableString (SIZE
(1..ub-serial-number))
replace with
X520SerialNumber ::= PrintableString (SIZE
(1..ub-serial-number))
Agree; the assignment operator (::=) is missing.
7. Section A.1
id-domainComponent AttributeType ::=
id-domainComponent
replace with
id-domainComponent AttributeType ::=
id-domainComponent }
I do not think that this is the correct change. The document says:
id-domainComponent OBJECT IDENTIFIER ::=
{ 0 9 2342 19200300 100 1 25 }
id-domainComponent AttributeType ::= id-domainComponent
domainComponent ::= IA5String
I think the middle statement should be deleted altogether. Also, the last
line must begin with a capital letter ("domainComponent" becomes
"DomainComponent").
8. ASN Module A.2: Do not have a new module OID for this.
A new OID for the modules was assigned quite some time ago. It should have
been included in this draft.
id-mod-pkix1-implicit OBJECT IDENTIFIER ::= { id-mod 19 }
9. Section A.2
anyPolicy OBJECT IDENTIFIER ::=
{id-ce-certificate-policies 0}
replace with
anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies 0}
(or fix the previous line)
Agree. X.509 (the 4th Edition) uses id-ce-certificatePolicies, and we
should too.
---------------- Algorithm Draft
ASN Module:
Fix:
PKIX1Algorithms88 { tbd }
I assigned id-mod-pkix1-algorithms a long time ago. It should have been
put into this draft.
id-mod-pkix1-algorithms OBJECT IDENTIFIER ::= { id-mod 17 }
Replace
cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
With
cofactor INTEGER OPTIONAL -- The integer h = #E(Fq)/n
My preference would be to replace the comma with "}" and delete the next
line. This is just taste. The comma needs to go.
------------------ Random
part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 does not have an
OID assigned to it
--- single name would be nice but not necessary. In the case of pkcs-9
however there should be a harmonization plan.
rfc2630.asn(254) : warning XXXXX: Arc naming collision between x9algorithm
and x9cm
Conflicts with what's in Algorithms draft
rfc2630.asn(262) : warning XXXXX: Oid value assigned to multiple symbols:
'dh-public-number' and 'dhpublicnumber'
Conflicts with what's in Algorithms draft
rfc2634.asn(204) : warning XXXXX: Arc naming collision between pkcs-9 and
pkcs9
Conflicts with what's in Part1 A.1
I do not see a problem with adopting the names from RFC 2630 and RFC 2634.
Russ