Sorry for the delay in responding. I've been away on business.
Is there more then one implementation to demonstrate
interoperability? If so, what modes of operation do they use?
To the best of our knowledge there is only one implementation. Anyone
else want to speak up?
In any case, I do not understand your second question. The documents do
not speak of "modes of operation" so I'm not sure what answer you're
expecting.
My company has been attempting to install PEM internally. PEM
had some flaws, but generally provided a fairly complete set of
workable specifications. The new draft is flawed and I see few
reasons to implement the new PEM-MIME.
This paragraph is confusing.
With respect to the implementation of PEM you're installing, is it an
internally developed one or someone elses? If the latter, which
version? I assume you've been in contact with them with respect to the
problems you're having.
With respect to PEM having flaws, do you mean PEM (RFC1421), PEM-MIME,
or the implementation of PEM you're working with?
With respect to the new draft having flaws, we want to hear about this.
None have been discovered for 2 IETF meetings and we'd certainly like to
fix everything we can before the documents are published.
The new draft (draft-ietf-pem-mime-07.txt) is a radical
departure from the original PEM RFCs (1421, 1422, 1423, 1424).
It has many new modes of operation that will complicate the
creation of interoperable implementations.
I'm not sure what you mean by modes of operation. The new draft
specifies how to add signature and encryption services to electronic
mail (MIME). What interoperability issues to see?
The internet draft
does not adequately describe what are the minimum m requirements
for a conformant implementation.
By not explicitly saying anything compliant implementations are required
to implement everything. This is consistent with many Internet
standards documents.
The new name forms, identifiers and trust models represent some
interesting technical ideas, but they are presented out of
context from the problems they originally were intended to
solve. They provide a variety of ways to solve issues with the
earlier PEM RFCs, but create too many ways to build a system.
The two new documents do not speak of trust models, by design. We are
explicitly divorcing what RFC 1421 and RFC 1422 married.
As for the name forms and identifiers, the problem we're trying to solve
is knowing the origin of a given public key. How is that different from
what they were originally intended solve?
Please describe the ways you see to build a system. While we agree
there are many ways to build a user agent that would make use of the PEM
technology, we only see one way to build PEM.
It is also interesting to note that there is no mention of PGP
in the text of the draft. Many of the changes from PEM to
MIME-PEM-07 were made mimic the trust model and functionality of
PGP. Why not admit in the specification that PEM has been
modified to use PGP public keys? Or am I wrong on this
interpretation...
You are incorrect. While we intentionally divorced what 1421 and 1422
married, thus opening the door for alternate trust models including
PGPs, we did it because one of the problematic issues associated with
the broad acceptance of PEM is the overhead of instantiating the
Internet certificate infrastructure. This is not to say the proposed
infrastructure is bad, rather we're recognizing the community interest
in other options.
Also, PEM and PGP keys are syntactically different, so they could not be
used directly within each other, although converting from one to the
other is straightforward.
Jim
binVub0tODoGC.bin
Description: application/pem-signature