Re: Format and standard for CSR

[Michael Richardson]

Robert Moskowitz  wrote:
> On 8/29/19 9:20 AM, Michael Richardson wrote:
>> Robert Moskowitz  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   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[







signature.asc
Description: PGP signature

Re: Format and standard for CSR

[Michael Richardson]

Robert Moskowitz  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   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

Re: Format and standard for CSR

[Viktor Dukhovni]

> On Aug 28, 2019, at 9:30 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.

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.

Re: Format and standard for CSR

[Salz, Rich]

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

Re: Format and standard for CSR

[Robert Moskowitz]

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

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

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

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  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  
wrote:
I am writing an Internet Draft that will include transmission of a CSR, 
so I need to reference the 

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 > 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:r...@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

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  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  
>>> 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
Description: S/MIME cryptographic signature

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

Re: Format and standard for CSR

[Michael Sierchio]

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

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