pem-dev
[Top] [All Lists]

re: re:Last Call

1995-05-05 07:34:00
       this specification has been under discussion for quite awhile.  The
nature of this current concern would seem to be nothing particularly new.
Why is this requirement being raised now?

It was raised in comments on the previous I-D (e.g., see extracts of my Jan 3 
and 4 postings below) and I thought the technical resolution was clear, but it 
is not reflected in the new draft.  I would support inclusion of the wording 
proposed by Paul Lambert.

Warwick
------------------
(From Jan 3 pem-dev posting):
In looking more into the potential deficiencies of MIME/PEM in the 
infrastructure environment, the main one seems to be the inability to carry an 
originator's certificate in the message header (which 1421 supported).  While 
this is not essential (as the recipient can always do a Directory retrieval) it 
could represent a substantial performance issue.  Most other application 
protocols which support digital signatures include provision for carrying (at 
least) one certificate along with the signature, so this looks like a MIME/PEM 
deficiency.  

Can the certificate be carried elsewhere in the message?  Perhaps the MIME/PEM 
authors can clarify.
-----------------------
(From Jan 4 pem-dev posting):
You are now getting close to satisfying my residual concern, namely how to 
optionally carry originator certificate(s) with the message.  I am afraid my 
reading of the Draft did not give me the clear impression that 
application/pemkey-data was intended to be used that way (although it does not 
preclude that) - the document seems much more to suggest that 
application/pemkey-data is a response to application/pemkey-request.  If indeed 
this is the intent, then I would request, at least, editorial changes which 
state that application/pemkey-data can be used that way plus include an 
example.  
In fact, I would suggest it go further - state that use of an attached 
application/pemkey-data is a "standard procedure" when originator 
certificate(s) 
is/are to be conveyed with a message.  Without such statement, it is unlikely 
interoperable implementations will result.
-------------------

<Prev in Thread] Current Thread [Next in Thread>