Another problem with openssl x509 -req -- default_enddate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Another problem with openssl x509 -req -- default_enddate

Robert Moskowitz
Another problem.  It is almost like it is not reading the CA selction?

openssl ca -config $dir/openssl-8021AR.cnf -extensions 8021ar_idevid
-notext -md sha256 \
       -in $dir/csr/$DevID.csr.pem -out $dir/certs/$DevID.cert.pem

processes the default_enddate

default_enddate= 99991231235959Z # per IEEE 802.1AR

to produce:

             Not Before: Aug 29 21:19:33 2017 GMT
             Not After : Dec 31 23:59:59 9999 GMT


But

    openssl x509 -req -extfile $dir/openssl-8021AR.cnf\
         -extensions 8021ar_idevid -days 365 -sha256\
         -set_serial 0x$(openssl rand -hex $sn)\
         -inform $format -in $dir/csr/$DevID.csr.$format\
         -outform $format -out $dir/certs/$DevID.cert.$format\
         -CAkeyform $format -CAkey
$dir/private/8021ARintermediate.key.$format\
         -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format

does not.  Even if I leave out the -days option.

I am thinking, do I need to use:

-extensions ca 8021ar_idevid

?? but that will probably be a syntax error.

thanks


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Viktor Dukhovni
On Tue, Aug 29, 2017 at 05:36:34PM -0400, Robert Moskowitz wrote:

> Another problem.  It is almost like it is not reading the CA selction?

Not "almost", but actually as expected, since "openssl x509 -req"
is not the ca(1) application.

>    openssl x509 -req -extfile $dir/openssl-8021AR.cnf \
>         -extensions 8021ar_idevid -days 365 -sha256 \
>         -set_serial 0x$(openssl rand -hex $sn) \
>         -inform $format -in $dir/csr/$DevID.csr.$format \
>         -outform $format -out $dir/certs/$DevID.cert.$format \
>         -CAkeyform $format -CAkey $dir/private/8021ARintermediate.key.$format \
>         -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format
>
> does not.  Even if I leave out the -days option.

It just creates a signed certificate based on the command-line
options, with only the extensions (-extfile option) read from a
configuration file.  The only concession to ca(1)-like behaviour
is support for a compatible serial number file (likely subject to
race conditions absent external locks to serialize invocations).

    * The version is 3, since you're using extensions
    * The serial number is specified on the command line.
    * The issuer DN is taken from the signing certificate.
    * The subject DN and public key are copied from the CSR

That just leaves the dates, and you get to specify the duration
from *now* with "-days".

With "x509 -req" you're building certs pretty much from the ground
up, a short C program will do exactly the same work, and could use
an explicit end date, rather than an increment of 'n' days from
the present.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Robert Moskowitz
Viktor,

thanks for the explanation. Obviously I read more into the man that was
really there:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

So back to openssl ca and deal with no way to directly create a DER
formatted cert.

Definitely a deficiency.

On 08/29/2017 07:25 PM, Viktor Dukhovni wrote:

> On Tue, Aug 29, 2017 at 05:36:34PM -0400, Robert Moskowitz wrote:
>
>> Another problem.  It is almost like it is not reading the CA selction?
> Not "almost", but actually as expected, since "openssl x509 -req"
> is not the ca(1) application.
>
>>     openssl x509 -req -extfile $dir/openssl-8021AR.cnf \
>>          -extensions 8021ar_idevid -days 365 -sha256 \
>>          -set_serial 0x$(openssl rand -hex $sn) \
>>          -inform $format -in $dir/csr/$DevID.csr.$format \
>>          -outform $format -out $dir/certs/$DevID.cert.$format \
>>          -CAkeyform $format -CAkey $dir/private/8021ARintermediate.key.$format \
>>          -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format
>>
>> does not.  Even if I leave out the -days option.
> It just creates a signed certificate based on the command-line
> options, with only the extensions (-extfile option) read from a
> configuration file.  The only concession to ca(1)-like behaviour
> is support for a compatible serial number file (likely subject to
> race conditions absent external locks to serialize invocations).
>
>      * The version is 3, since you're using extensions
>      * The serial number is specified on the command line.
>      * The issuer DN is taken from the signing certificate.
>      * The subject DN and public key are copied from the CSR
>
> That just leaves the dates, and you get to specify the duration
> from *now* with "-days".
>
> With "x509 -req" you're building certs pretty much from the ground
> up, a short C program will do exactly the same work, and could use
> an explicit end date, rather than an increment of 'n' days from
> the present.
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Viktor Dukhovni
On Wed, Aug 30, 2017 at 12:17:09AM -0400, Robert Moskowitz wrote:

> So back to openssl ca and deal with no way to directly create a DER
> formatted cert.
>
> Definitely a deficiency.

Not really a deficiency, as the certificates in question need to
be squirreled away in PEM format in the CA's "certs/" directory
(compatibility with longstanding behaviour), and are much more
easily exported, via email etc., in PEM format.

It is trivial to convert a PEM certificate to DER.  Mind you,
if I wanted a specialized CA, I'd go with the C API, where
you can do *exactly* what you want:

  * Store metadata in a SQL database.
  * Read keys directly from PKCS8
  * Write certs directly in DER form
  * ...

The openssl ca(1) program is to some extent just a demo, that meets
only the simplest needs.  Perhaps you were looking for a turnkey
CLI, but you have a specialized new use-case, and it is not entirely
surprising that it is not directly supported.

Patches to support missing features that might be of use to others
are welcome.  The software evolves best through community participation.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Robert Moskowitz
Viktor,

On 08/30/2017 12:59 AM, Viktor Dukhovni wrote:

> On Wed, Aug 30, 2017 at 12:17:09AM -0400, Robert Moskowitz wrote:
>
>> So back to openssl ca and deal with no way to directly create a DER
>> formatted cert.
>>
>> Definitely a deficiency.
> Not really a deficiency, as the certificates in question need to
> be squirreled away in PEM format in the CA's "certs/" directory
> (compatibility with longstanding behaviour), and are much more
> easily exported, via email etc., in PEM format.
>
> It is trivial to convert a PEM certificate to DER.  Mind you,
> if I wanted a specialized CA, I'd go with the C API, where
> you can do *exactly* what you want:
>
>    * Store metadata in a SQL database.
>    * Read keys directly from PKCS8
>    * Write certs directly in DER form
>    * ...
>
> The openssl ca(1) program is to some extent just a demo, that meets
> only the simplest needs.  Perhaps you were looking for a turnkey
> CLI, but you have a specialized new use-case, and it is not entirely
> surprising that it is not directly supported.
>
> Patches to support missing features that might be of use to others
> are welcome.  The software evolves best through community participation.

I am not a coder.  In fact I pretty much stopped writing code in the
'80s.  I DID some programming in B on Honeywells.  The only place where
B escaped Bell Labs.  I never got to C; moved on to other IT support
work, then to coding standards in English...

I have some limited scripting skills.

So as much as would like to contribute code, with maybe 2 years to
retirement, I am not going to pick it up.  But who knows, maybe I will
take a C programming course as part of my retirement activities.

I kind-of slept on this issue. I know that I can convert a PEM cert to
DER, but I have been thinking about 'what of the other portions, like
the keypair file?'  I woke up a little clearer head, and realized, that
a truly constrained device won't even bother with DER, but just store
the raw keypair.  So doing the creation all PEM and converting what is
needed as DER to DER may be a realistic approach.

thanks for your help on this.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Viktor Dukhovni
On Wed, Aug 30, 2017 at 06:03:03AM -0400, Robert Moskowitz wrote:

> I woke up a little clearer head, and realized, that a truly
> constrained device won't even bother with DER, but just store the raw
> keypair.

FWIW, Apple's boot firmware stores the signature key as the raw
RSA key bits in little-endian form for efficient computation on
Intel CPUs.  No PEM or ASN.1 in sight.

Similarly, there's no ASN.1 in the DNSSEC DNSKEY RDATA format.
For RSA just the key and exponent octets:

    $ echo $(dig +short +nosplit -t dnskey . | grep -w 256 | awk '{print $NF}' | openssl base64 -A -d | hexdump -ve '/1 "%02x"')
    030100018bf1ad038eba329d673fb7ecffa82f897b7b7e7fd1d887fe66484c68e5a787fcd591902b8d8737149f92249a8629cf477b746108630b7f77357e13a2b4a24c9cbbe9305675d34e902fc8686a9c6f87ab53e9d0ef99362dfd2822903ba930a4dd4933601aa12831c702bd94762b44eee14b0dca17e2704b0a8687e45b5fc6152ac93951bb44415c012e28efab3914c53f45e0039be5cd5997b700a46fd1bc1a49c7b8ed63540c2edecc8f4551c4ac86da5ecd7e8da86f5962fe0e8e3077e940f932f7fa9524fb32930f69dcabb65b24165d768f53ecf663be7b56254cc81c83166511408e98be57ba60874a352985d980351b880d6cf682c02f528b49d9a82183

The "03" is the exponent length (limited to 255 octets), the "10
00 01" is the usual F_4 (65537) exponent, and the remaining 512
nibbles are the RSA modulus.

So indeed, you'd not be the first to consider a special-purpose
concise format.  It is somewhat surprising that the applications
you're considering use X.509 certificates at all, rather than just
raw public keys.  With expiration times in the year "9999", the
extra bloat of certificates is perhaps just useless baggage.
Admittedly, I don't know how the security model in question relates
to the real-world constraints of the supply chain, who gets to sign
certificates for devices allowed to participate, and whether a
certificateless public key database might have been a realistic
option.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Robert Moskowitz


On 08/30/2017 10:33 AM, Viktor Dukhovni wrote:

> On Wed, Aug 30, 2017 at 06:03:03AM -0400, Robert Moskowitz wrote:
>
>> I woke up a little clearer head, and realized, that a truly
>> constrained device won't even bother with DER, but just store the raw
>> keypair.
> FWIW, Apple's boot firmware stores the signature key as the raw
> RSA key bits in little-endian form for efficient computation on
> Intel CPUs.  No PEM or ASN.1 in sight.
>
> Similarly, there's no ASN.1 in the DNSSEC DNSKEY RDATA format.
> For RSA just the key and exponent octets:
>
>      $ echo $(dig +short +nosplit -t dnskey . | grep -w 256 | awk '{print $NF}' | openssl base64 -A -d | hexdump -ve '/1 "%02x"')
>      030100018bf1ad038eba329d673fb7ecffa82f897b7b7e7fd1d887fe66484c68e5a787fcd591902b8d8737149f92249a8629cf477b746108630b7f77357e13a2b4a24c9cbbe9305675d34e902fc8686a9c6f87ab53e9d0ef99362dfd2822903ba930a4dd4933601aa12831c702bd94762b44eee14b0dca17e2704b0a8687e45b5fc6152ac93951bb44415c012e28efab3914c53f45e0039be5cd5997b700a46fd1bc1a49c7b8ed63540c2edecc8f4551c4ac86da5ecd7e8da86f5962fe0e8e3077e940f932f7fa9524fb32930f69dcabb65b24165d768f53ecf663be7b56254cc81c83166511408e98be57ba60874a352985d980351b880d6cf682c02f528b49d9a82183
>
> The "03" is the exponent length (limited to 255 octets), the "10
> 00 01" is the usual F_4 (65537) exponent, and the remaining 512
> nibbles are the RSA modulus.
>
> So indeed, you'd not be the first to consider a special-purpose
> concise format.  It is somewhat surprising that the applications
> you're considering use X.509 certificates at all, rather than just
> raw public keys.  With expiration times in the year "9999", the
> extra bloat of certificates is perhaps just useless baggage.
> Admittedly, I don't know how the security model in question relates
> to the real-world constraints of the supply chain, who gets to sign
> certificates for devices allowed to participate, and whether a
> certificateless public key database might have been a realistic
> option.

I am the author of HIP (rfc 7401) and to a large extent, raw public keys
for Identity.  I started this work in January '99, before most of the
current stuff using raw keys came around.  I know that Apple parallel
developed much of their work.  Stewart Cheshire has said that if he had
found the time to read HIP, he would have used it for the call home
function.  And I know all about DNSKEY, as a few years into HIP, we
chose to use the DNSKEY format in the HI parameter payload, dropping our
own format.

I also worked with Sigma Design on Zwave 2.0 which uses raw EC25519 keys.

But not everyone agrees with me on raw keys, and I do recognize the need
of 3rd party identity assertions.  And this is, to a large measure, what
IEEE 802.1AR-2009 Secure Identities offers.  But 1AR is only about the
Identities, and not how to manage and bootstrap from iDevIDs to
lDevIDs.  The IETF workgroup, ANIMA is working on this.  And Michael
Richardson, who just joined this list, is one of the authors on those
documents.  Oh, and NETCONF is working on it for network infrastructure
devices with their 'zero touch' drafts. Of course those are NOT
constrained devices...

Getting 802.1AR-2009 does require an IEEE login, but is free thanks to
us IEEE 802 meeting attendees paying a bit extra to IEEE to make our
docs free 6 months after publication.  Of course the addendum that is in
final prep is NOT available free (to non-attendees), but the changes do
not impact this discussion.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Michael Richardson
In reply to this post by Viktor Dukhovni
Viktor Dukhovni <[hidden email]> wrote:
    > The openssl ca(1) program is to some extent just a demo, that meets

I'd actually suggest that it be either:
  1) ripped out of the source code, and turned into a seperate "application".
  2) pushed internal to the source code (not installed), and used only for
     running regression tests.

The two actions are not mutually exclusive!

There are probably a dozen commands to which such an approach would help
improve both the APIs, and make the code easier for (others) to innovate
with.

    > only the simplest needs.  Perhaps you were looking for a turnkey
    > CLI, but you have a specialized new use-case, and it is not entirely
    > surprising that it is not directly supported.

+10.

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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Michael Richardson
In reply to this post by Viktor Dukhovni

Viktor Dukhovni <[hidden email]> wrote:
    > So indeed, you'd not be the first to consider a special-purpose
    > concise format.  It is somewhat surprising that the applications
    > you're considering use X.509 certificates at all, rather than just
    > raw public keys.  With expiration times in the year "9999", the
    > extra bloat of certificates is perhaps just useless baggage.

We are leveraging the political unity behind 802.1AR (which defines the
IDevID). As a profile it's pretty thin, relying extensively (but
appropriately) on IETF documents,  yet still leaving a bunch of stuff rather
under-specified.

While devices possessing IDevIDs don't need all the cert chain stuff,
the network infrastructure validating them may need it.  Given supply chain
complexity, it could well be in the IDevID that linking back to the
manufacturer requires a chain of certificates.  (My KitchenAid dishwasher is
made and serviced by Whirlpool, but was sold to me by Sears.  I'd expect
Sears' certificate to be in the electronic invoice)

    > Admittedly, I don't know how the security model in question relates
    > to the real-world constraints of the supply chain, who gets to sign
    > certificates for devices allowed to participate, and whether a
    > certificateless public key database might have been a realistic
    > option.

No, it's just not.
In the 6tisch (constrained) version of BRSKI, which is at:
   https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/b84347549d469806067cf60b323444f97a98ee83/dtsecurity-zerotouch-join-00.txt?at=master&fileviewer=file-view-default
until the rename of the document is approved.  Section 2.2 explains that the
constrained device will have/need only the raw public key of the manufacturer, and
will treat the IDevID as a blob.  The private key should be stored in
whatever form is most convenient for computation, like the Apple boot loader
does.   Still, some people will have TPMs with complicated interfaces.

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


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Michael Richardson
In reply to this post by Viktor Dukhovni

Viktor Dukhovni <[hidden email]> wrote:
    > So indeed, you'd not be the first to consider a special-purpose
    > concise format.  It is somewhat surprising that the applications
    > you're considering use X.509 certificates at all, rather than just

I meant to add in my previous email, that the reason to use the PKIX
containers is because we need the identifiers for algorithms and hashes, and
the like so that we can have algorithm agility going forward.

Of course, we could get that from some other format: OpenPGP for instance.
Alas, none are very popular in the greater world.  Maybe CWT will win out
where PGP (for keys and signatures) did not... but I don't think the industry
outside of the IETF is ready for that yet. (The IETF is not even ready...)

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


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another problem with openssl x509 -req -- default_enddate

Robert Moskowitz
In reply to this post by Michael Richardson


On 08/30/2017 09:22 PM, Michael Richardson wrote:

> Viktor Dukhovni <[hidden email]> wrote:
>      > So indeed, you'd not be the first to consider a special-purpose
>      > concise format.  It is somewhat surprising that the applications
>      > you're considering use X.509 certificates at all, rather than just
>      > raw public keys.  With expiration times in the year "9999", the
>      > extra bloat of certificates is perhaps just useless baggage.
>
> We are leveraging the political unity behind 802.1AR (which defines the
> IDevID). As a profile it's pretty thin, relying extensively (but
> appropriately) on IETF documents,  yet still leaving a bunch of stuff rather
> under-specified.

By intent.

> While devices possessing IDevIDs don't need all the cert chain stuff,
> the network infrastructure validating them may need it.  Given supply chain
> complexity, it could well be in the IDevID that linking back to the
> manufacturer requires a chain of certificates.  (My KitchenAid dishwasher is
> made and serviced by Whirlpool, but was sold to me by Sears.  I'd expect
> Sears' certificate to be in the electronic invoice)

Actually there was extensive discussion that this would be LDevIDs. The
manufacturer is KitchenAId.  Their IDevID.  So that Whirlpool can
service it, a Whirlpool LDevID.  We could not come to any consistent
scenario on Sears as the Merchant.  No real difference than Target
selling a TracPhone.  What interaction do they have after the sale?

Or there is NO KitchenAid Identity in the machine.  They were just a job
shop for Whirlpool so only a Whirlpool IDevID...

You missed out on all the fun discussions, Michael.  You just get to
pick up the pieces!

The real drivers, at the time was Cisco and Aruba for their phones...

>      > Admittedly, I don't know how the security model in question relates
>      > to the real-world constraints of the supply chain, who gets to sign
>      > certificates for devices allowed to participate, and whether a
>      > certificateless public key database might have been a realistic
>      > option.
>
> No, it's just not.
> In the 6tisch (constrained) version of BRSKI, which is at:
>     https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/b84347549d469806067cf60b323444f97a98ee83/dtsecurity-zerotouch-join-00.txt?at=master&fileviewer=file-view-default
> until the rename of the document is approved.  Section 2.2 explains that the
> constrained device will have/need only the raw public key of the manufacturer, and
> will treat the IDevID as a blob.  The private key should be stored in
> whatever form is most convenient for computation, like the Apple boot loader
> does.   Still, some people will have TPMs with complicated interfaces.

Lots of groups taking the basics and putting them together in a way that
SHOULD work for them...

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users