On Apr 3, 2017 16:07, "Sean Leonard" <[email protected]> wrote:
On 4/3/2017 5:54 AM, Logan Widick wrote:
I think that having separate URIs to reduce bloat is a good idea. I
understand that the client needs to send the CSR as a field in the
new-order request payload for security. However, in the server response,
could the CSR be a URI that would allow the client to retrieve the CSR that
the client submitted in DER format? So, could new-order requests look like:
{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}
And the server's order response look like:
{
csrLink: "[link to DER encoded CSR]"
certificate: "[link to DER encoded certificate]"
chains: [array of links to chains as suggested by Niklas]
//rest of fields in order response here (except for "csr")
}
The wrinkle with this proposal is that CSRs are likely non-public data.
They could contain personally identifiable information in the metadata, or
other random stuff. It is undesirable to have a link that has to be
maintained for the lifetime of the order history, which could be harvested
by search engines or otherwise made public. Typically CAs harvest the
public key and discard the rest (after verifying the authenticity of the
CSR). Therefore, I am not in favor of URIs for CSR data.
Since CAs would harvest data from CSRs and then discard the rest after
authenticity checks, and the identifiers would appear elsewhere (in the
authorizations), could the "csr" field apply to the new-order request and
be absent from the order object?
The case for URIs for issued end-entity certificates is half-half.
Certificates are public documents, but it's an extra round-trip and you
have to save the same amount of state on the client side (i.e., the
certificate URI).
The case for URI(s) for CA certificates in the validation chain is
strongest, since they are unlikely to change and are reused across many
customers. Basically "de-duplication". On the other hand, there are
business/usability advantages to packaging up "everything you need to run
your web server" in one neat package.
When certificates are embedded in order objects, won't the order objects
get quite large?
For consistency, I think the chain links (when retrieved) should be
concatenated DER.
I am in favor of DER. :) (But less sure about whether links are desirable
in the first place.)
I could have sworn that when certificate retrieval is done over the wire,
CMS (PKCS #7) is an IETF standardized type for blobs of certificates. Oh
yeah, here it is:
RFC 5280 Section 4.2.2.1 (it's repeated elsewhere):
HTTP server implementations accessed via the URI SHOULD specify the
media type application/pkix-cert [RFC2585
<https://tools.ietf.org/html/rfc2585>] in the content-type header
field of the response for a single DER encoded certificate and SHOULD
specify the media type application/pkcs7-mime [RFC2797
<https://tools.ietf.org/html/rfc2797>] in the
content-type header field of the response for "certs-only" CMS
messages. For FTP, the name of a file that contains a single DER
encoded certificate SHOULD have a suffix of ".cer" [RFC2585
<https://tools.ietf.org/html/rfc2585>] and the
name of a file that contains a "certs-only" CMS message SHOULD have a
suffix of ".p7c" [RFC2797 <https://tools.ietf.org/html/rfc2797>].
Consuming clients may use the media type
or file extension as a hint to the content, but should not depend
solely on the presence of the correct media type or file extension in
the server response.
Just sayin'... ;-)
It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to
concatenated DER certificates plus a little bit of goo at the beginning and
end (which can be ignored/skipped). Here is a dump of a .p7s file I have
lying around using asn1js:
SEQUENCE(2 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.2
[0](1 elem)
SEQUENCE(5 elem)
INTEGER1
SET(0 elem)
SEQUENCE(1 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.1
[0](3 elem)
SEQUENCE(3 elem)
SEQUENCE(3 elem)
SEQUENCE(3 elem)
SET(0 elem)
In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which
start with SEQUENCE. Rip and go.
Finally, here is how you convert from p7s to textual certificates:
openssl pkcs7 -inform DER -in yourfile.p7s -print_certs
The advantage of the command-line/OpenSSL recipe above, is that you are
guaranteed that the output will only be -----BEGIN CERTIFICATE----- things.
Non-certificates shall not pass.
That already standardized type would be better.
On Apr 3, 2017 06:29, "Niklas Keller" <[email protected]> wrote:
One potential issue I can see with embedding certificates with the
currently proposed format directly into orders are alternative chains.
Chains usually do not change between orders, so they could be kept with
separate URIs for cachability and less bloat in the order response.
e.g.
"certificate": base64url(derEncodedCertificate),
"chains": [
"https://.../chain"; <https://.../chain>,
"https://.../alternate-chain"; <https://.../alternate-chain>
]
Regards, Niklas
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
