[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)
Magnus and Carlisle,
A few comments below.
Magnus Nystrom wrote:
>
> Carlisle,
>
> Thanks for taking our views into account. A few comments on the new
> versions of rfc2510bis and rfc2511bis:
>
> -The waiting status issue:
> We feel that it is a bit disturbing that no polling req/rep
> PKIMessages are defined. The result is that the protocol does not
> define what to do in those instances when a "waiting" status is
> returned. It would be much more satisfying to define this within CMP
> than rely on some underlying transport to do the polling (with what
> PKIMessage? - and it would have to be defined for all conceivable CMP
> transports, too...)
>
> -While the use of an empty SubjectPublicKey to indicate the type of
> key an end-user would like to have centrally generated seems
> possible, it will not give the user a possibility to indicate
> e.g. desired public exponent or modulus length. A method which is
> more flexible would perhaps be preferable?
In rfc2510bis, for other key formats, allowing a user
to choose domain parameters known to be viable or key
lengths of sufficient strength would also be a plus.
----
Note that in rfc2510bis under "B2. Algorithm Use
Profile", useful references for HMAC and ECDSA
could help readers. These are columns could
include X9.71 and X9.62.
> -The CMPCertificate type: Looking in rfc2511-bis-01, it does not
> appears as if there is a corresponding framework suggested to allow a
> requester to indicate that it would like, e.g. a WTLS Certificate to
> be returned. Is this intended? One could imagine, e.g., a
> CertTemplateChoice.
I notice that a couple of places in rfc2510bis state
"See Appendix D and [rfc2511bis] for CertReqMessages
syntax", and that Appendix D does provide direction
for "specifying a template for a certificate other
than an X.509v3 public-key certificate".
The use of type AttributeTypeAndValue here seems
quite flexible enough to handle any type of
certificate format. This is a far less restrictive
design than using a choice type. It opens up market
possibilities rather than closing them.
> -ASN.1 modules:
>
> I also took a few minutes to check the ASN.1 with my syntax checker.
>
> RFC 2511bis: There is one simple problem and one slightly harder one.
>
> a) You need to remove the "CRMF" before "DEFINITIONS" - the module has
> already been named above to "PKIXCRMF".
>
> b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
> in turn, imports definitions from ITU/ISO specifications rather
> than PKIX RFCs. Now this would be ok, unless it was for the fact
> that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
> CMS imports from modules written in 1993 syntax. This creates a
> mess for those using commercial compilers, since UTF8Strings (used
> in ISO documents but defined explicitly in PKIX documents) aren't
Actually the situation is even worse than
described here. The use in IETF modules of
class UNIVERSAL tags is not valid ASN.1 under
any version of the ASN.1 standards.
It is an IETF concoction made up I believe
to allow old X.208 and X.209 based tools to
make use of new ASN.1 types never defined
in those standards, but defined for years
and years now in the current ASN.1 standards.
This kludge allowed old tools to provide
much needed national language support without
being updated or corrected, and allowed folks
with copies of X.208 and X.209 (which have not
been corrected or amended for years) to avoid
buying the current ASN.1 standards.
At one time, the current ASN.1 standards were
not available except for a charge, and there
were various copies of different versions of
X.208 and X.209 floating around for free.
But the X.680 and X.690 series standards are
currently free for download from the itu.ch
web site. Up until a couple of weeks ago at
least, when I last checked, all you had to do
was to enter an email address to get three
free documents. New email address, three more
standards.
> supported in 1988 but are in 1993, so one cannot compile these
> modules with either a "1988" switch or a "1993" switch. My advice
> would of course be to move to 1993/1997 ASN.1 altogether, but if
Agreed. This is the best possible solution.
Not only does it eliminate the concoction
noted above, it allows the use of other new
types and encoding rules by adopters of IETF
standards.
> this is not possible due to PKIX policies, I'd suggest a change to
> make CMS dependent on PKIX modules rather than external modules
> (yes, I realize that CMS is owned by S/MIME and not by PKIX).
Not sure that this will really do more than
cover the problem with a little sand. What
will a compliant tool kit do if it discovers
a value of type RELATIVE-OID in an ANY or
embedded in an OCTET STRING? Crash and burn
is my guess. But this new type is already
being used to advantage in the new ANSI X9.84
biometrics standard and in the design of the
new compressed (see asn-1.com/x968.htm) domain
certificate syntax in ANSI X9.68:2.
> RFC2510bis:
>
> c) You state that there is no PKCS #10 ASN.1 module defined; this is
> not correct. RFC 2986 does contain a (1993) module.
>
> d) I would prefer if X9.68 certificates were not mentioned in this
> document.
I would prefer that these X.509 based domain certificates
were still mentioned, but that the text be changed from
"X9.68" to "X9.68:2". Only the profile part of this series
that Magnus worked on has been dropped by the X9F1 working
group. The other part of this series, part one, was being
edited by Rich Ankney. I've taken this edit work on and will
attempt to progress the work in the coming year.
> e) Since you already import from rfc2459 modules, why not also import
> the UTF8String definition from there?
It is no more valid really to import an invalid
type definition than to simply define the type
using invalid notation. It only hides the problem
for the casual reader.
> Other than that I found the very same errors as James Manger did.
>
> -- Magnus
>
> On Fri, 2 Mar 2001, Carlisle Adams wrote:
>
> > Hi,
> >
> > For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> > revisions to the previous drafts which, I believe, address all comments
> > received (both privately and on the list) in the past 3 months. I feel that
> > both documents are now ready to progress.
> >
> > The documents can be found at the following locations:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
> >
> >
> > The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
> >
> > p.30: added a comment on the "waiting" status regarding the
> > possible need for a polling mechanism in the transport layer and allowing
> > the possibility of polling PKIMessages in a future version of this spec.
> > (You might recall Magnus asking for this on the PKIX list....).
> >
> > p.33: removed tag "[1]" from publicKeyMAC field (to align
> > with syntax in RFC 2511).
> >
> > p.39: changed "OCTET STRING" to "string" in comment
> > regarding utf8Pairs ("OCTET STRING" was confusing to some people).
> >
> > p.63: added a comment regarding the way in which a
> > requester could indicate a preference for algorithm and parameters with
> > respect to centrally-generated key pairs (Magnus also asked how this could
> > be done and I should have given him this answer, but didn't think of it at
> > the time...).
> >
> > p.67: removed the position-dependence requirement for
> > requests in cr and kur (at least a couple of people have asked for this on
> > the list, including Magnus).
> >
> > p.75: clarified what gets signed if the AltCertTemplate
> > control is used (someone asked for this on the list).
> >
> > p.80: (see p.30 above).
> >
> > p.85: (see p.39 above).
> >
> > p.86: added the certReqId field to CertStatus (I had done
> > this in the body of the spec, but forgot to copy it to this appendix!).
> >
> > The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
> >
> > pp.1 and 13: changed the work affiliation for Mike Myers.
> >
> > p.10: added a missing parenthesis in the second line of the
> > comment under encValue.
> >
> > p.12: added a reference to PKCS11.
> >
> > p.16: changed "OCTET STRING" to "string" in comment
> > regarding utf8Pairs ("OCTET STRING" was confusing to some people).
Phil
----
Phillip H. Griffin Griffin Consulting
http://asn-1.com Secure ASN.1 Design & Implementation
p: +1-919-832-7008 1625 Glenwood Avenue
f: +1-919-832-7390 Hayes Barton at Five Points
e: phil@xxxxxxxxx Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------