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

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 4 Feb 2005 21:35:00 -0000

Yes, we just want to express that which is the current practice. 

I guess that limits to binary and base64 encoded .cer file and binary
.p7c

Except from this I agree to Matt that it would be nice to loosen up the
requirement on what certificates that is included in a .p7c file. Maybe
"certificate path" is too restrictive. I have no problem with Matt's
suggested change here.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Russ Housley
> Sent: den 4 februari 2005 05:21
> To: Matt Cooper; Stefan Santesson
> 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"
> >
>
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/
+Q
> 29u
>
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05
le
> HRQ
> >...
> >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: Russ Housley <[email-masked]>
Date: Fri, 04 Feb 2005 16:54:57 -0500

I have no problem including certificate that may be useful in path 
construction in the .p7c.

Russ