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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 10 Feb 2005 13:11:51 -0000

So, how about this:

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

HTTP server implementations accessed via the URI SHOULD use the
appropriate MIME [ref] content-type for the certificate containing 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 CMS 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.

---------

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Matt Cooper
> Sent: den 9 februari 2005 02:32
> To: Stefan Santesson; 'Russ Housley'
> Cc: [email-masked]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> 
> 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
> 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: [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,
> 
> 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/>
> > > >
> > > >
>