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

From: "Matt Cooper" <[email-masked]>
Date: Thu, 3 Feb 2005 15:15:04 -0500

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):
 
===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: Thu, 03 Feb 2005 15:38:46 -0500

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.

(
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

===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.

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.)

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

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: "Matt Cooper" <[email-masked]>
Date: Thu, 3 Feb 2005 18:29:20 -0500

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/+Q29u
dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ
...
BhcnA===

Matt Cooper
Orion Security Solutions

________________________________

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

	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):

	 
	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.)

	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 08:21:01 -0500

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

---

From: Juergen Brauckmann <[email-masked]>
Date: Fri, 04 Feb 2005 15:38:30 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Hi.

In Chapter 1 you are saying:
   RFC 3280 [PKIX1] has provided for bottom-up discovery of
   certification paths through the Authority Information Access
   extension, where the id-ad-caIssuers access method may specify one or
   more accessLocation fields that contain references to CA certificates
   superior to the certificate containing this extension.

That is, the intention of id-ad-caIssuers is to provide a link to the
direct issuer of the certificate containing the extension, and to CA
certificates that are further up the chain.

But chapter 4.2.1.1 in RFC 3280 says (4th paragraph):
  The id-ad-caIssuers OID is used when the additional information lists
  CAs that have issued certificates superior to the CA that issued the
  certificate containing this extension.

If I'm reading this sentence, I understand that you should only provide
a link to the *issuer* of the CA of the certificate containing the
extension, one level higher up in the hierarchy.
=> Is my interpretation of the sentence wrong?

Please correct me... .

Regards,
  Juergen

---

From: Russ Housley <[email-masked]>
Date: Fri, 04 Feb 2005 14:41:42 -0500

Juergen:

The Authority Information Access Extension provides information about the 
issuer of the certificate that contains the extension.

Russ

At 09:38 AM 2/4/2005, Juergen Brauckmann wrote:

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iQEVAwUBQgOI5tbYU3wuWc8tAQE3Jgf+K+4rBYoYZ157ZtKVhdVBBzxqecV8wTeO
>o2lnTF+PrgdxrLErSykC7IelS9qDv9tV382ZiX2jRSTEqe3rwr1gWILRby6n3lup
>QkhU8w3LzsN8lhcTpo9RhsWaZJ+4ReTSFPN4rIGQBd9qiOB3FNw/Jug84pzI/hV3
>FFNH4B/dSkmsSoY8SvcqRxa2GZrWOQKjPPEFtZIaIVYR1g6h6+PBkj5WyMwyE4Rw
>h0+mO2/gRfL5YRTbfKMFjW03PCXuAr/C6RalQJJuzoObE7fiHE//DqpIK6lV7EKX
>QmGrf3GzvwIv+mBZqzhhW6sMGtZstUIwm2l9QrNL0U4j+kfbt+Js8A==
>=WC/B
>-----END PGP SIGNATURE-----

---

From: "Matt Cooper" <[email-masked]>
Date: Mon, 7 Feb 2005 12:27:18 -0500

Russ,

TRUE|FALSE: On the server, you intend for the certificate file (stored 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

-----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:

Russ

At 06:29 PM 2/3/2005, Matt Cooper wrote:

>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.
>
>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
>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
>
>         First, I'd like to say I'm happy to see this come out, this is 
>a needed addition for CRLs.
>
>         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.
>         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?
>         "HTTP server implementations accessed via the URI SHOULD use 
>the appropriate MIME content-type for the certificate file.  
>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.)
>
>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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 07 Feb 2005 18:26:18 +0100

Russ Housley wrote:
>> When I read this it
> that binary will be used in this case, but base64 and other encodings 
> are not prohibited.
> 

Russ, it's still not clear to me whether you and Matt are talking about
the same thing:

I think Matt is talking about the file containing yet another
encapsulated MIME part. As I understand the example he gave the header
lines would *not* be the HTTP header lines. These would be the header of
an additional MIME part stored in the certificate file.

Ciao, Michael.

---

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

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

-----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 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.
>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.
>
> >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 
> >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg
> >g/
> >+Q29u
> >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X
> >05
> >leHRQ
> >...
> >BhcnA===
> >
> >
> >Matt Cooper
> >Orion Security Solutions
> >         First, I'd like to say I'm happy to see this come out, this 
> >is a needed addition for CRLs.
> >
> >extension)
>or
> >         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
> >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."
> >
> >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.)
> >
> >single binary DER encoded certs-only PKCS#7 file (indicated by the 
> >.p7c file

---

From: Russ Housley <[email-masked]>
Date: Tue, 08 Feb 2005 13:41:22 -0500

Matt:

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

---

From: Michael Ströder <[email-masked]>
Date: Wed, 09 Feb 2005 10:58:13 +0100

Russ Housley wrote:
 >
> 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.

This should be made more clear in the text.
I also interpreted it like Matt did.

Ciao, Michael.

--
Michael Ströder
http://www.stroeder.com