Format and standard for CSR

[Blumenthal, Uri - 0553 - MITLL]

>  Uri, Greetings!

Hello there! ;-)

> On 8/28/19 6:09 PM, Blumenthal, Uri - 0553 - MITLL wrote:
 > > Do you have an ASN.1 definition fit the content of CSR, or are you willing to create one?
>
 > For now working with ASN.1.

In that case, I would use one of the available defined standards, which are well-supported by already existing Open Source software.

If you don’t have any extreme need for compactness of the binary representation – DER has been around long enough, is understood well enough, and the codecs are reasonably-well debugged. That would be my first choice.

If you do have a very austere link, perhaps UPER or OER, as they provide a tighter/more-compact encoding.
In addition to ASN.1, I found XER to be a good format for documenting examples (sample packets/messages), but I wouldn’t send it over the wire (though some people do that – I won’t say what I think of them).  

> >  IMHO, DER would be a pretty good choice, fat better than something home-brewed and non-standard.
>
> take a look at rfc 7049.  This is the standard for data objects over constrained networks.  Then look at
> draft-birkholz-core-coid

I did. They favor schema-less data. I abhor it.  But then, I knew some people who didn't like to sit down and think before starting to write code. ;-)

Their argument against PER is

      Few (if any) IETF protocols have adopted one of the several variants
      of Packed Encoding Rules (PER).  There could be many reasons for
      this, but one that is commonly stated is that PER makes use of the
      schema even for parsing the surface structure of the data stream,
      requiring significant tool support.  There are different versions of
      the ASN.1 schema language in use, which has also hampered adoption.

I'm not sure I agree with the "significant tool support" above. I use https://github.com/vlm/asn1c.git, and it provides all I need (actually, I use the https://github.com/mouse07410/asn1c.git fork, as I also use APER, which it supports ;).

I'm also surprised that they did not provide encoding comparison with one of the PER variants (UPER, APER), or OER. It would've been far more instructive, IMHO, than comparing CBOR and BER to BSON.

> For work being done to define by a good team to meld x.509 stuff with CBOR.

[Un?]fortunately, I don't have time to invent a new encoding standard, implement + debug it, and some time down the road find that I need to extend it because it doesn't cover the case I didn't think of back then.

IMHO, the problem with X.509 is not with DER encoding, so I don't see much benefit in expressing it in CBOR instead.

> "The wonderful thing about standards is there are so many to choose from."

Which is yet another reason to stop and check whether really none of the existing ones could satisfy your needs. ;-)

Thanks!

P.S. You mentioned that CSR is in PEM. PEM (Privacy Enhanced Mail) is a base64 encoding of (typically) DER. PEM is your payment by space for your DER not being mangled en-route by mail servers. You may base64-encode any binary format, if you suspect it would traverse binary-data-unfriendly links. If you want to dump CSR content, first convert it to DER (strip PEM encoding) via, e.g., "base64 --decode -i my.csr -o my.der", and then dump DER content with, e.g., "dumpasn1 my.der".

P.P.S. Re. CSR being a one-time document - that's true more often than not, but unless you only intend to use *one* CA that you control, it might make sense to stick to publicly-accepted formats, or at least something that can be easily/automatically converted to them.
--
Regards, 
Uri

Sent from my iPhone

On Aug 28, 2019, at 17:49, Robert Moskowitz <mailto:rgm at htt-consult.com> wrote:
CSR is an object in a container that goes over a 'wire'.   Sometimes the wire is very small (BT4) so the container needs to be tightly designed.

It should be a standard, not something totally off the wall.  Well I could do it in CBOR, and probably will at some point, but for now something more common in PKIX world should work.

Mangle it, stuff it down the wire, de-mangle it and use it.  For now I am referencing RFC 2986.

What do you suggest.  Please reference documents that can be referenced in the document.

Thanks

On 8/28/19 5:23 PM, Michael Sierchio wrote:

I don't see the point in DER encoding for a CSR – The RA and CA decide the composition of the cert, based on the rules and CPA that they follow, and of course any cert issued will be in DER format, and may include reordering or modified/expanded extensions and key use restrictions.  A CSR is basically an assertion that includes pubkey, proof of possession of the private key, and any request elements required by policy.  It's a one-time document that needs to be validated precisely once.


On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz <mailto:rgm at htt-consult.com> wrote:
I am writing an Internet Draft that will include transmission of a CSR, 
so I need to reference the proper source.  No more sloppy, "well it 
works...".

Some digging said it is in PKCS#10 - CSR.  But I did not stop with that.

A bit more googling lead me to RFC 4211...

When I create a CSR with:

    openssl req -config openssl-intermediate.cnf\
        -key ./private/client.key.pem \
        -subj "$DN" -new -out ./csr/client.csr.pem

What format is this?  Are there better, more concise formats (e.g. DER?) 
for transmission over constrained networks?

I can dump it with

    openssl req -text -noout -verify -in ./csr/client.csr.pem

But that does not really tell me the format, only what is in the cert.

Thanks



-- 

"Well," Brahmā said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." 

- The Mahābhārata



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190829/3f36a8ad/attachment.bin>