Format and standard for CSR

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Format and standard for CSR

Robert Moskowitz
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

Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Robert Moskowitz
Peter, thank you for the response.

On 8/28/19 10:09 AM, Bowen, Peter wrote:
> I think you want RFC 2986 (https://tools.ietf.org/html/rfc2986 ).  That is the most recent "PKCS #10" specification that I have seen and should align with what `openssl req` creates.  Adding '-outform DER' to your command will output in DER; the default output is PEM which is defined in RFC 7468 (https://tools.ietf.org/html/rfc7468 ).

This will be within a HIP registration exchange (rfc 8003), so PKCS #10
in DER seems best.

> Depending on your use case, you may want to consider using a SPKAC formatted request instead.  See `openssl spkac` and https://en.wikipedia.org/wiki/SPKAC for more info.

Considering the process, the PKCS10 fits better.

thanks for the references.

>
> On 8/28/19, 6:49 AM, "openssl-users on behalf of Robert Moskowitz" <[hidden email] on behalf of [hidden email]> 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
>      
>      
>

Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Michael Sierchio
In reply to this post by Robert Moskowitz

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Robert Moskowitz
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Blumenthal, Uri - 0553 - MITLL
Do you have an ASN.1 definition fit the content of CSR, or are you willing to create one?

IMHO, DER would be a pretty good choice, fat better than something home-brewed and non-standard.

Regards,
Uri

Sent from my iPhone

On Aug 28, 2019, at 17:49, Robert Moskowitz <[hidden email]> 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 <[hidden email]> 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


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Robert Moskowitz
Uri, Greetings!

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.

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

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

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

There was a reference point to Grace Hopper saying this in '58.


Regards,
Uri

Sent from my iPhone

On Aug 28, 2019, at 17:49, Robert Moskowitz <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: 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:[hidden email]> 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:[hidden email]> 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




smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Viktor Dukhovni
> On Aug 28, 2019, at 9:30 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> 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.

CSRs are signed objects (proof of possession).  The signature is
over the DER form of the RequestInfo.  Therefore, the only natural
encoding for CSR is DER, or base64-encoded DER wrapped in PEM
ASCII armour.

Adding X.509 extensions to CSRs is sadly rather more complex than
one might have hoped for, but that's only an issue if you have to
write low-level library code to construct CSRs.  If you have such
a library, just serialize to DER and you're done.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Michael Richardson
In reply to this post by Robert Moskowitz

Robert Moskowitz <[hidden email]> 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.

RFC2986 is PKCS10.
RFC7030 references that, I don't think that there is anything newer.
But, maybe I've mis-understood your question?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [

Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Robert Moskowitz


On 8/29/19 9:20 AM, Michael Richardson wrote:

> Robert Moskowitz <[hidden email]> 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.
>
> RFC2986 is PKCS10.
> RFC7030 references that, I don't think that there is anything newer.
> But, maybe I've mis-understood your question?

To bring up 7030, yes you have.

7030 is not something you want to run over a highly constrained network,
involving a highly constrained device.  It does provide some good
guidelines for 'completeness'.  Is ANIMA using it?  And ANIMA is not
just constrained devices.

For this project there are strong arguments to do all registration stuff
within HIP messages.  At least for initial design.

It is not my job in this project to declare a winner in best CSR format
design.  For the initial specification, I need to do a best effort on
current practice.  PKCS#10 seems to be that.

You may be one of the parties at the Hackathon.   And perhaps the only
one on this list.


Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Salz, Rich
In reply to this post by Blumenthal, Uri - 0553 - MITLL

A CSR is most commonly a PKCS#10 object and therefore defined in ASN.1 and encoded in DER.

https://github.com/openssl/openssl/blob/master/crypto/include/internal/x509_int.h#L53

 

Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Robert Moskowitz


On 8/29/19 11:20 AM, Salz, Rich wrote:

A CSR is most commonly a PKCS#10 object and therefore defined in ASN.1 and encoded in DER.

https://github.com/openssl/openssl/blob/master/crypto/include/internal/x509_int.h#L53

 


thanks, Rich

It all fits together now


Reply | Threaded
Open this post in threaded view
|

Re: Format and standard for CSR

Michael Richardson
In reply to this post by Robert Moskowitz

Robert Moskowitz <[hidden email]> wrote:
    > On 8/29/19 9:20 AM, Michael Richardson wrote:
    >> Robert Moskowitz <[hidden email]> 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.
    >>
    >> RFC2986 is PKCS10.
    >> RFC7030 references that, I don't think that there is anything newer.
    >> But, maybe I've mis-understood your question?

    > To bring up 7030, yes you have.

    > 7030 is not something you want to run over a highly constrained network,
    > involving a highly constrained device.  It does provide some good guidelines
    > for 'completeness'.  Is ANIMA using it?  And ANIMA is not just constrained
    > devices.

ANIMA BRSKI is an RFC7030 extension.
ANIMA constrained-BRSKI (draft-ietf-anima-constrained-voucher) is an
extension of ACE's draft-ietf-ace-coaps-est, which is a constrained version
of 7030.  [Yes, I'm an author on all of those]
It still uses CSRs (binary DER, never PEM encoded).

    > For this project there are strong arguments to do all registration stuff
    > within HIP messages.  At least for initial design.

    > It is not my job in this project to declare a winner in best CSR format
    > design.  For the initial specification, I need to do a best effort on current
    > practice.  PKCS#10 seems to be that.

We are going to be using CSR until we have something like CoID.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [






signature.asc (497 bytes) Download Attachment