[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FTP and HTTP



Russ,

The use of application/octet-string would seem suitable if
the object is truely a file.

I do not believe one intends, however, to deny other
objects transferred using http. Consider adding
language which explicitely allows other mime
types to be used, without standarizating their
form.

To your paragrah 

"For convenience, the names of files that contain certificates should
   have a suffix of ".cer".  Each ".cer" file contains exactly one
   certificate, encoded in DER format.  Likewise, the names of files
   that contain CRLs should have a suffix of ".crl".  Each ".crl" file
   contains exactly one CRL, encoded in DER format."

One might add a phrase: 'Other http resources usable with
this mechanism may have alternative formats and naming conventions."

--------

Consider, by way of example, this msg. There is
an electronic vard attachment. Within, I have hopefully placed
an http URL, which points to an interactive page
which parties may used to download my cert in
a variety of formats used by various security applications.
This action is intended to replace the need to attach
my cert chain to each signed message, which is
rather a waste of resources particularly for those
who do not bother to verify signatures.

 Peter.

 
-----Original Message-----
From: Russ Housley <housley@spyrus.com>
To: ietf-pkix@tandem.com <ietf-pkix@tandem.com>
Date: Tuesday, September 23, 1997 2:55 PM
Subject: FTP and HTTP


>Here is FTP/HTTP document that was slit out from PKIX Part 2.
>It is also being sent to the I-D repository.
>
>There is one detail to complete before last call: the assignement
>of MIME types for use with HTTP.  Does anyone have a preference?
>
>Russ

Attachment converted: Lutefisk:Peter Williams.vcf 3 (TEXT/R*ch) (0001BF3B)
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 19 (????/----) (0001BF3C)