Subject: RE: draft-ietf-pkix-crlaia-00.txt comments

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 8 Feb 2005 19:17:20 -0000

Matt,

Do you have any proposed wording?
Feel free to make a suggestion.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Matt Cooper [mailto:[email-masked]]
> Sent: den 8 februari 2005 19:50
> To: 'Russ Housley'; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> I knew we would get to the same page eventually. :)
> 
> I'm glad to hear the answer is negative. I, and several others I have
> spoken
> to, took the text in the draft to indicate this extra MIME encoding
was
> the
> proposed requirement. So, I think we simply need to reword that
section to
> be very clear on this point.
> 
> Best Regards,
> 
> Matt Cooper
> Orion Security Solutions
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (Mob) 703.981.2269
> (Off) 703.917.0060 x. 30
> (Fax) 703.917.0260
> Visit our website!
> http://www.orionsec.com
> 
> 
> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2005 1:41 PM
> To: Matt Cooper; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> Matt:
> 
> Now I understand the issue.  Sorry it took so long for me to
understand
> the
> comment.
> 
> FALSE.
> 
> I expect the server to store a binary .cer and .p7c file.  The only
MIME
> encoding will be applied by the transport protocol.  HTTP will MIME
> encode.
> FTP will not.
> 
> Russ
> 
> At 12:27 PM 2/7/2005, Matt Cooper wrote:
> >Russ,
> >
> >TRUE|FALSE: On the server, you intend for the certificate file
(stored
> >TRUE|on
> >the server's hard disk) to be MIME encoded.
> >
> >The question has nothing to do with HTTP. It could be FTP or NFS for
> >all it matters. What the draft says (to me at least) is that you are
> >supposed to MIME encode the data *BEFORE* the protocol encoding ever
> enters
> the picture.
> >This results in the client receiving a MIME encoded file regardless
of
> >transport protocol.
> >
> >Best Regards,
> >
> >Matt Cooper
> >Orion Security Solutions
> >1489 Chain Bridge Road, Suite 300
> >McLean, Virginia 22101
> >(Mob) 703.981.2269
> >(Off) 703.917.0060 x. 30
> >(Fax) 703.917.0260
> >Visit our website!
> >http://www.orionsec.com
> >
> >
> >-----Original Message-----
> >From: Russ Housley [mailto:[email-masked]]
> >Sent: Friday, February 04, 2005 8:21 AM
> >To: Matt Cooper; [email-masked]
> >Cc: [email-masked]
> >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> >
> >Matt:
> >
> >MIME supports many encoding types, including binary and base64.  I
> >think that binary will be used in this case, but base64 and other
> >encodings are not prohibited.
> >
> >We should probably say that binary encoding MUST be supported.
> >
> >Russ
> >
> >At 06:29 PM 2/3/2005, Matt Cooper wrote:
> >
> > >Perhaps I was not clear either.  I didn't think you were attempting
> > >to eliminate the HTTP MIME encoding.  And believe me, I'm the first
> > >one to cheer having a naming convention for this purpose!
> > >
> > >Are you saying that your intent was only to apply the MIME encoding
> > >to how the HTTP server should be serving up the files to the
client?
> > >Not trying to be difficult, I just want to be sure we're on the
same
> > >page as the text reads quite differently to me.
> > >
> > >It reads (to me) that you intend for the hosted file to be MIME
> > >encoded rather than binary.  Specifically, as [A MIME encoded
> > >application/pkcs7-mime "certs-only" file  as specified in RFC 2797
> > >[CMC]"].  When I read this it indicated to me that I am supposed to
> > >MIME encode the PKCS#7 and name the resultant MIME text file with a
> > >.p7c extension.  E.g., place the following file content on my web
> server:
> > >
> > >MIME-Version: 1.0
> > >Content-Type: application/pkcs7-mime;
> > >         smime-type="certs-only";
> > >         name="cacerts.p7c"
> > >Content-Transfer-Encoding: base64
> > >Content-Disposition: attachment;
> > >         filename="cacerts.p7c"
> > >
> >
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg
> > >g/
> > >+Q29u
> >
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X
> > >05
> > >leHRQ
> > >...
> > >BhcnA===
> > >
> > >
> > >Matt Cooper
> > >Orion Security Solutions
> > >1489 Chain Bridge Road, Suite 300
> > >McLean, Virginia 22101
> > >(Mob) 703.981.2269
> > >(Off) 703.917.0060 x. 30
> > >(Fax) 703.917.0260
> > >Visit our website!
> > >http://www.orionsec.com
> > >
> > >
> > >________________________________
> > >
> > >From: Russ Housley [mailto:[email-masked]]
> > >Sent: Thursday, February 03, 2005 3:39 PM
> > >To: Matt Cooper; [email-masked]
> > >Cc: [email-masked]
> > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> > >
> > >
> > >Matt:
> > >
> > >We were not clear.  We did not intend to eliminate the MIME
encoding
> > >which is normally present with HTTP.  The MIME types are specified
in
> > >the referenced documents, I believe.  Rather, we were also stating
a
> > >naming convention for the files that are obtained.
> > >
> > >Russ
> > >
> > >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> > >
> > >
> > >         First, I'd like to say I'm happy to see this come out,
this
> > >is a needed addition for CRLs.
> > >
> > >         All my comments refer to the following snippet extracted
> > >from the draft
> > >         (
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> > ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>
):
> > >
> > >         ===begin===
> > >            When the http scheme is specified, the URI MUST point
to a
> > >            certificate file.  The certificate file MUST contain
> > >either a single
> > >            DER encoded certificate (indicated by the .cer file
> > >extension)
> >or
> > >            contain a certification path (indicated by the .p7c
file
> > >extension):
> > >
> > >               .cer   A single DER encoded certificate as specified
in
> > >                      RFC 2585 [PKIX-CERT].
> > >
> > >               .p7c   A MIME encoded application/pkcs7-mime "certs-
> only"
> >file
> > >                      as specified in RFC 2797 [CMC].
> > >         ===end===
> > >
> > >         Unless this has been required in another document that I
am
> > >unaware of, we should use not use "MIME encoded" for this purpose
for
> > >the following
> > >reasons:
> > >         1. It creates burden on the client.  Why should the client
> > >need a MIME decoder to verify a CRL?
> > >         2. It creates burden for CA's and CA operators.  They may
> > >have to learn how to manually encode a PKCS#7 in a MIME structure
if
> > >their CA does not output this for them. This is error prone and may
> > >lead to
> >problems.
> > >         3. Clients must handle one case as binary and the other
case
> > > as
> >text
> > >         4. Web servers already return MIME types for data; another
> > >MIME layer is not needed
> > >
> > >         It is not too much to expect that the relying party
software
> > >can distinguish between a binary cert and a binary p7c file. (For
> > >example, MS CAPI already does this for AIA)  However, to make life
> > >easier for the client, could we throw in appropriate use of MIME
> > >types on
> >the web server?
> > >Perhaps something like this:
> > >
> > >         "HTTP server implementations accessed via the URI SHOULD
use
> > >the appropriate MIME content-type for the certificate file.
> > >Specifically, the HTTP server SHOULD return the content-type
> > >application/pkix-cert for a single DER encoded certificate and
> > >application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients
> > >SHOULD use the MIME type as a hint, but should not depend solely on
> > >the presence of the correct MIME type in the server response."
> > >
> > >         Calling for the contents of the p7c to be "a certification
> > >path" is too restrictive in my mind.  It would be better to leave
> > >this wide open and say something like "contain one or more
> > >certificates that may be helpful to the relying party."  This
leaves
> > >it up to the implementer to put in any certificates that may be
> > >useful for path construction regardless of whether we have common
> > >trusted roots.  (They may also wish to not include the entire path,
> > >but instead only the CRL signer cert, which then has another AIA in
> > >it.)
> > >
> > >         Suggest rewording the text something like this :
> > >
> > >         When the HTTP scheme is specified, the URI MUST point to a
> > >certificate file. The certificate file MUST be either a single
binary
> > >DER encoded certificate (indicated by the .cer file extension) or a
> > >single binary DER encoded certs-only PKCS#7 file (indicated by the
> > >.p7c file
> > >extension) containing one or more certificates that may be helpful
to
> > >the relying party.
> > >
> > >
> > >         Matt Cooper
> > >         Orion Security Solutions
> > >         1489 Chain Bridge Road, Suite 300
> > >         McLean, Virginia 22101
> > >         (Mob) 703.981.2269
> > >         (Off) 703.917.0060 x. 30
> > >         (Fax) 703.917.0260
> > >         Visit our website!
> > >         http://www.orionsec.com <http://www.orionsec.com/>
> > >
> > >

---

From: "Matt Cooper" <[email-masked]>
Date: Tue, 8 Feb 2005 20:32:02 -0500

Hi Stefan,

One nit with regard to the wording - The way you have used "certificate
file" makes it seem like a new term when I read it. Is this used in other
docs to collectively describe multiple file types containing certificates?
If no, I think you may want to find a different way to say this so it
doesn't sound like new terminology, or, if not, should it be defined
explicitly?  Fairly minor point in any event.

You can decide what to do with the above comment; I stuck with that
terminology below. I was thinking something along these lines:

-------
When the HTTP scheme is specified, the URI MUST specify the location of a
certificate file. The certificate file MUST be either a single binary DER
encoded certificate (indicated by the .cer file extension) file or a single
binary DER encoded certs-only PKCS#7 [ref] file (indicated by the .p7c file
extension) containing one or more certificates.

HTTP server implementations accessed via the URI SHOULD use the appropriate
MIME [ref] content-type for the certificate file.  Specifically, the HTTP
server SHOULD use the content-type application/pkix-cert [ref] for a single
DER encoded certificate and application/pkcs7-mime [ref] for a certs-only
PKCS#7.  Consuming clients may use the MIME type and file extension as a
hint to the file content, but should not depend solely on the presence of
the correct MIME type or file extension in the server response.
-------

Best Regards,

Matt Cooper
Orion Security Solutions

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, February 08, 2005 2:17 PM
To: Matt Cooper; Russ Housley
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments

Matt,

Stefan Santesson

> spoken to, took the text in the draft to indicate this extra MIME 
> encoding
was
section to
understand
MIME
(stored
of
client?
same
encoding
in
a
this
to a
file
in
am
for
if
case
software
use
leaves
binary
to