Re: [openssl-dev] ETA: TLS 1.3 release

[David Woodhouse]

On Wed, 2017-04-19 at 12:14 +, Salz, Rich via openssl-dev wrote:
> > Out of curiosity, what's the ETA for TLS 1.3?
> > [1] mentions April 5 as the release date (which was two weeks ago).
> > 
> > [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html
> 
> That's an akamai blog, not an openssl statement :)  And that post is
> misleading, it should have said "available" not "released."
> 
> The code is in master.

Have the DTLS_get_data_mtu() and related tests been expanded to cover
it?

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-12-14 at 18:03 -0500, James Bottomley wrote:
> > I think we're talking about two different things. What I mean is that 
> > a given application shall never have to deal with files and PKCS#11 
> > for a given single object.
> 
> Sure (as in I thought that went without saying).

If only :)

> Yes ... I was mostly reacting against your statement that the keys
> needed to be inside the TPM for PKCS11 use.

Ok. I didn't (mean to) say that.

> > And you'll note that none of those examples need extensions to the
> > PKCS#8 format to store arbitrary PKCS#11 attributes such as 
> > CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because 
> > it's their own database and they can do what they like; they don't 
> > have to store it in a PKCS#8 or similar file.
> 
> OK, so as long as you're happy with pkcs11 being used on TPM key files
> which are then loaded as needed via the pkcs11 interface, I think we're
> on the same page. 

I think so, but *ick*, don't say "files".

I'm happy with PKCS#11 being used, where the PKCS#11 provider keeps its
own database (completely separate from the application, like NSS
softokn, SoftHSM, GNOME Keyring already do it).

We don't normally use the word "files" when we talk of high-level
concepts involving those three examples, even though SoftHSM actually
does use individual files for storage. So let's avoid confusion by not
talking about 'files' for the TPM one either. In this usage model, the
application never sees a file.

The application uses a PKCS#11 token. That token has its own storage
which as far as the application is concerned, is magical.


There is *another* usage model, where the application actually sees a
file akin to the existing -BEGIN TSS KEY BLOB- files (and for
which we ought to extend PKCS#8 to do it properly). That usage model
should also be supported.

>  I'm coming to the conclusion that we need the files
> in pairs and the public key can supply the attributes ... it's more or
> less how gnome keyring currently does it.

You want it *exactly* how GKR (or the other examples I gave) do it,
with the sole exception that RSA keys can be wrapped by the TPM
instead. I had also been talking about using Skylake's SGX software
enclaves to do a similar augmentation to software tokens.

> > The example you give with GNOME keyring doing SSH keys is a 
> > *different* special case. There it's automatically discovering the 
> > files in a known location (~/.ssh/id_*) and has to infer what it can 
> > from them, but still it's only exposing them over PKCS#11 in a 
> > standard way. There's none of the horridness for 'here, load *this* 
> > file into the token', is there? You can do that with ssh-add perhaps, 
> > but that's mostly orthogonal to what we're talking about here.
> 
> OK, so a token can be writeable as well, but I expect the object to be
> loaded into the token to be correctly serialised according to the
> protocol and also possibly wrapped.
> 
> > > So this is the actual problem: the TPM only stores private keys. 
> > >  The public key thing (can be simple, cert or something more fancy)
> > > isn't known to it.  All pkcs11 searchers find the public key in the
> > > public objects and then look for the private key by id and label 
> > > (this is what the standard recommends).
> > 
> > Which part of the standard are you referring to? It isn't really that
> > prescriptive about how you look things up, as far as I was aware.
> 
> Section 4.8 in the current OASIS base spec:
> 
> The CKA_ID field is intended to distinguish among multiple keys. In
> the case of public and private keys, this field assists in handling
> multiple keys held by the same subject; the key identifier for a
> public key and its corresponding private key should be the same. The
> key identifier should also be the same as for the corresponding
> certificate, if one exists.
> 
> In practice it seems that most things use CKA_ID and CKA_LABEL if they
> both exist.

OK, right. So it isn't just NSS; *most* things will automatically try
to find a private key once they've already been pointed at the cert, by
matching CKA_ID and/or CKA_LABEL. Sure, you *can* explicitly point at
separate cert and privkey, but you generally shouldn't need to.

> > All of the above is for *wrapped* keys, of course. Not keys stored
> > persistently in the TPM.
> 
> I'm starting to think keys permanently loaded into the TPM aren't the
> right way to go ... 

Right, which is why I stopped there at the observation that we weren't
talking about that :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote:
> > Hm, this seems odd. If something is stored in a file then exposing it
> > through PKCS#11 doesn't make sense at all. Do not attempt to use
> > PKCS#11 for any file access.
> 
> OK, so the horse has already left the stable on that one with TPM
> enabling gnome-keyring for ssh keys because it exports *every* key over
> pkcs11.  Since it does, I thought I'd play about with it a bit to see
> how it would work.  The below is what I found out playing around.

I think we're talking about two different things. What I mean is that a
given application shall never have to deal with files and PKCS#11 for a
given single object. Like the nss-pem horridness, where we create an
object whose CKA_LABEL is the filename, and we want the soft token to
go and load that file.

You seem to be talking about software-based PKCS#11 tokens which happen
to use their *own* files behind the scenes, but all the *application*
ever knows about is sane PKCS#11 operations. That is absolutely fine.
There's plenty of examples of that — including SoftHSM, GNOME keyring,
and NSS's softokn.

And you'll note that none of those examples need extensions to the
PKCS#8 format to store arbitrary PKCS#11 attributes such as CKA_LABEL,
CKA_PRIVATE, CKA_APPLICATION or anything else. Because it's their own
database and they can do what they like; they don't have to store it in
a PKCS#8 or similar file.

The example you give with GNOME keyring doing SSH keys is a *different*
special case. There it's automatically discovering the files in a known
location (~/.ssh/id_*) and has to infer what it can from them, but
still it's only exposing them over PKCS#11 in a standard way. There's
none of the horridness for 'here, load *this* file into the token', is
there? You can do that with ssh-add perhaps, but that's mostly
orthogonal to what we're talking about here.

> So this is the actual problem: the TPM only stores private keys.  The
> public key thing (can be simple, cert or something more fancy) isn't
> known to it.  All pkcs11 searchers find the public key in the public
> objects and then look for the private key by id and label (this is what
> the standard recommends).

Which part of the standard are you referring to? It isn't really that
prescriptive about how you look things up, as far as I was aware.

>   The problem is that the label they use isn't
> going to be the UUID, so we need the private key to be labelled by what
> its public counterpart expects to use the TPM for arbitrary keys, like
> certificate private keys (or even gpg or ssh private keys).  The UUID
> thing works for stuff that expects separate private and public key
> descriptions, like gnutls and openssl, but not for anything that uses
> the full pkcs11 protocol (like netscape).

Right, you need a full software token for stuff like NSS. But didn't
you already do that in GNOME keyring? It stores the CKO_CERTIFICATE
objects just like it always did, and now it's capable of storing the
actual private key of a CKO_PRIVATE object in TSS-wrapped form, but the
other attributes are still stored in its database just as they always
were?

And we could make SofTHSM and NSS support the same things.

None of *that* needs to touch on the PKCS#8 storage format at all. That
is *only* relevant to the case where the application is given a *file*
with the private key it's supposed to use, and there is no PKCS#11 in
sight.

All of the above is for *wrapped* keys, of course. Not keys stored
persistently in the TPM.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
> 
> So the proposal is to have a TPM specific value for PrivateKeyAlgorithm
> (which would have to be proposed as an OID) and use PrivateKeyInfo for
> the key?  That could be made to work.

Right.

> The slight fly in the ointment that's worrying me is that I need a key
> format that works for pkcs#11 tokens as well.  The problem here is that
> TPM keys don't have an id or a label and that's pretty much a
> requirement of using a pkcs#11 token, so the pkcs#11 code has to be
> able to set these attributes on the key files.  I was originally
> thinking of putting them into the PEM header with a pkcs11- prefix.  I
> suppose I can do the same with the attributes and some manufactured OID
> prefix with the CKA_ parameters we're interested in as a suffix but
> it's messy.

Hm, this seems odd. If something is stored in a file then exposing it
through PKCS#11 doesn't make sense at all. Do not attempt to use
PKCS#11 for any file access.

Seriously, if you have any doubts about that at all, go read nss-pem
and ponder its operation. Then drink until you've forgotten most of it,
but remember that PKCS#11 isn't to be used for accessing stuff that you
have in a file.

PKCS#11 can sanely be used for keys which are persistently stored *in*
the TPM storage, which *do* have a UUID which can be used as CKA_ID.
(Or maybe as CKA_LABEL since CKA_ID really SHOULD be the pubkey hash,
if we can manage that).

If you're talking about a PKCS#11 token which has its *own* storage of
wrapped keys, then sure — you can keep whatever metadata you like. But
you don't need that to be part of the PKCS#8 standard format. In fact
if you want this you're probably better off extending SoftHSM to stored
wrapped keys and use the TPM for operating them.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> The reason for that is that the PEM forms which contain
> the key algorithm in the PEM header were considered legacy types and new 
> methods
> should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
> discourage their use.
> 
> In this case the reason is different: the header doesn't contain the algorithm
> type but a string which an ENGINE can handle. So it isn't a "legacy format"
> but a custom one.
> 
> So if we wanted to go down this route all that is needed to get a form of this
> functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.

I am not entirely averse to the idea of saying that TPM, at least as of
2.0, should have a wrapped-key storage format which is based in PKCS#8
rather than doing its own thing.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

[David Woodhouse]

On Thu, 2016-12-08 at 16:22 -0800, James Bottomley wrote:
> 
> I'm guessing you mean this:
> 
> https://www.trustedcomputinggroup.org/wp-content/uploads/TSS_Version_1.2_Level_1_FINAL.pdf
> 
> ?  It still doesn't tell you who the expected parent of the key would
> be, which is the problem I'm currently trying to solve.

Right, in S3.23 ("Portable Data") or thereabouts. And yes, it doesn't
indicate the parent key. As discussed, the TssBlob structure there is
fairly pointless which is presumably why the TPM ENGINE didn't use it,
and just dumped the actual blob (which I later put into an OCTET_STRING
 in the PEM files, IIRC).

I was hoping that the TPM 2.0 spec would fix that, maybe?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

[David Woodhouse]

On Tue, 2016-12-06 at 22:30 +0100, Richard Levitte wrote:
> Oh
> 
> I think I aired some thoughts on using PEM headers a very long while
> ago, but that never came into fruition, among others because I ended
> up doubting that it would be the best way in the long run.
> 
> These days, the use of PEM headers is considered old and kinda sorta
> deprecated, even though OpenSSL still produces encrypted private key
> PEM files that uses headers for the encryption metadata.  It seems
> that PKCS#8 is prefered "out there".
> 
> So I have to wonder, is PEM really the right way to go for this?
> Would it be just as possible to wrap a TSS key with a PKCS#8
> container, and use the associated attributes for the external data?
> Just a thought, though...  I can't do more than throw around ideas,
> considering how little I know about TPM.

I would definitely suggest that we *don't* want to do it with PEM
headers. Just put the additional information into the binary ASN.1
structure.

The 2.0 version of the TssBlob (from §3.23 of the 1.2 spec) should
hopefully contain all the auxiliary information we need, without having
to stick it in PEM headers.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Fri, 2016-12-02 at 08:03 -0800, James Bottomley wrote:
> >   Most likely (and hopefully) the latter keys will be handled over
> > PKCS#11 rather than directly.
> 
> I have reservations about scaling pkcs11 into a multi-tenant
> environment, but I agree, in principle it is possible.  I'm looking at
> trying to do it better for TPM now (well, it's the next thing to get to
> on my list).

There are two problems with PKCS#11 and TPM.

Firstly, PKCS#11 only supports one PIN per PKCS#11 provider. If each
key can have its *own* PIN, that doesn't work so well. You can play
deprecated tricks and have a separate slot for each key, but that
quickly gets horrid, and more so when you consider the second
problem...

Secondly, wrapped keys don't actually exist in the TPM so there's no
'URI' that you can refer to them by; they are ephemeral. The encrypted
key is actually *in* the PEM file, and gets loaded into the TPM for it
to decrypt and use.

So to cope with this through PKCS#11 you'd need some kind of nasty hack
where it loads the PEM file and a new token magically "hotplugs" into
existence. We already have something that's *almost* this horrid, with
the nss-pem abomination that NSS uses to load PEM files; you call the
C_CreateObject() method using an object 'label' which is actually a
file name it's vile, and it's not really a model we want to follow.

I think we really do need native support for loading these PEM files,
and not to attempt to make it work through PKCS#11.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl)

[David Woodhouse]

On Fri, 2016-12-02 at 14:04 +0100, Richard Levitte wrote:
> It does now for everything but PKCS#12 files.  Those are trickier, and
> I'm working on it.

Nice.

> Speaking of...  do you mind if I pilfer from that Makefile.am for our
> tests?

Not at all; please do. You're welcome to use anything in the test suite
under the OpenSSL licence. With the caveat/exception that bits of it
came from Nikos — but that was mostly the ocserv test harness which
isn't the bit you want.

I really will augment it with password/charset torture testing one of
these days...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Fri, 2016-11-25 at 08:54 +0100, Nikos Mavrogiannopoulos wrote:
> On Thu, Nov 24, 2016 at 4:33 PM, David Woodhouse <dw...@infradead.org> wrote:
> > On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> > > On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse <dw...@infradead.org> 
> > > wrote:
> > > > > Locales is not the only thing you have to worry about. UTF-8 and 
> > > > > UTF-16
> > > > > can express the same string in various (different) ways, so they 
> > > > > cannot
> > > > > be directly used as passwords. I have recently added RFC7613
> > > > > "normalization" to gnutls, to address the differences.
> > > > > 
> > > > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > > > 
> > > > Right. You normalise to NFC, yes? That's what my draft recommends. It's 
> > > > a
> > > > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > > > better than PKCS#8 :)
> > > 
> > > NFC normalization is one step of RFC7613. I think recommending RFC7613
> > > is better than making any recommendation.
> > 
> > Hmmm I'd be happier if RFC7613 had any mention of using its
> > profiles for key derivation. (And even happier if the PKCS#12 and
> > PKCS#8 standards mandated its use!)
> 
> They predate it by several years. At the time they were published very
> few could conceive how UTF-8/unicode would look like.

The original PKCS documents predated the publication of Unicode by a
few months in 1991. Sure, *NOBODY* could have predicted in early 1991
that some kind of coherent approach to character sets would be a good
idea ☺

And yes, UTF-8 came later (1992, I believe¹) but isn't necessary. Even
the original RSA PKCS#12 uses Unicode, and specifies the use of
BMPString for key derivation. Although it neglected to specify any
normalisation. (Did normalisation exist, at that point?)

Even by the time PKCS#5 was brought into the IETF fold in 2000
(RFC2898) it was fairly clear that you kind of had to agree on the
mapping of password characters to numbers, and it was "recommended that
applications follow some common text encoding rules. ASCII and UTF-8
[27] are two possibilities."

I know, it's useless to look back and, with the benefit of hindsight,
criticise the original standards. I'm mostly just reacting to your
"excuse". And standards *do* evolve. PKCS#8 was updated again in
RFC5958 and even then it could have been mandated that UTF-8/NFC be
used for key derivation.

> > This is really something that should be required of the software which
> > *creates* the key file. I've tried to limit my draft to the *use* of
> > existing files — but on the plus side, that means I can say things like
> > "try X and if that doesn't work try Y", at least for the file
> > decryption, if not for hardware.
> > So sure, if there is existing software which is *creating* key files
> > and using the rules in RFC7613 when it does so, then it makes sense for
> > me to suggest that.
> 
> gnutls after 3.5.7 will be using RFC7613 for all types of passwords.

Including *rejecting* passwords such as '' as
shown in example 17 in §4.3? Or do we end up in a situation where
applications which are *loading* key files should attempt such a
password anyway, even though it *shouldn't* work?

And how about PKCS#12? RFC7613 mandates UTF-8 but we just ignore that
bit and do UTF-16 instead for PKCS#12, with the rest of the RFC7613
rules?

-- 
dwmw2

¹ https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse <dw...@infradead.org> wrote:
> > > Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> > > can express the same string in various (different) ways, so they cannot
> > > be directly used as passwords. I have recently added RFC7613
> > > "normalization" to gnutls, to address the differences.
> > > 
> > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > 
> > Right. You normalise to NFC, yes? That's what my draft recommends. It's a
> > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > better than PKCS#8 :)
> 
> NFC normalization is one step of RFC7613. I think recommending RFC7613
> is better than making any recommendation.

Hmmm I'd be happier if RFC7613 had any mention of using its
profiles for key derivation. (And even happier if the PKCS#12 and
PKCS#8 standards mandated its use!)

This is really something that should be required of the software which
*creates* the key file. I've tried to limit my draft to the *use* of
existing files — but on the plus side, that means I can say things like
"try X and if that doesn't work try Y", at least for the file
decryption, if not for hardware.

So sure, if there is existing software which is *creating* key files
and using the rules in RFC7613 when it does so, then it makes sense for
me to suggest that.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote:
> That being said, though, your recommendation should probably specify
> (after discussing it) exactly what keys, certs and so on should be
> supported. Otherwise, everyone will have a slightly different idea of
> what's reasonable and you will end up in the same space as today... 

Oh $DEITY yes, that's the whole point. And I don't think I've left much
ambiguity there. As ever, suggestions for improvement would be most
welcome...

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.1

4.1.  File name

   Many applications support the use of certificates and private keys
   stored in files on the file system.  Such applications MUST support
   the use of files in any of the formats mandated in Section 5, in both
   PEM and DER containers.

   Applications MUST NOT require the user to provide any additional
   hints regarding the contents of the file, such as whether the
   contents are in PEM or DER format.  This MUST be determined by the
   application itself, automatically.

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#formats

5.  File formats

   ...

   Applications MUST accept all of the formats below without requiring
   any additional information from the user or the configuration.  Where
   an application has an existing "key format" or similar option which
   has historically been required to disambiguate between formats
   (either the formats below or between PEM and DER), application SHOULD
   NOT document this use of that legacy option as current practice, and
   SHOULD default to working it out automatically.  Application authors
   who cannot achieve this SHOULD consider taking up goat farming, and
   never touching a cryptographic application again in their life.

5.1.  PKCS#1 and other native ASN.1 encodings

   Applications MUST support unencrypted private keys:

   o  RSA keys in PKCS#1 form as defined by [RFC2437]
   o  DSA keys in the ASN.1 form defined by OpenSSL and documented in
  Appendix B (if DSA keys are supported at all)
   o  ECDSA keys in the form defined by [RFC5915]
   o  EdDSA keys in the form defined by [I-D.ietf-curdle-pkix]

5.2.  PKCS#8

   Applications MUST support keys stored in PKCS#8 form as defined in
   [RFC5208] for all key types.  Applications MUST support unencypted
   PKCS#8 objects, as well as those which are encrypted in various forms
   as discussed in Section 6.1.

   Applications MAY support the updated version of PKCS#8 is defined in
   [RFC5958]. ...

5.3.  PKCS#12

   Applications MUST support the use of certificates and keys from
   PKCS#12 objects ([RFC7292]), encrypted with any of the the methods
   mandated in Section 6.1.  Applications MUST support the use of at
   least SHA1 and SHA256 HMAC, and SHOULD support other HMAC algorithms
   which become common.

6.  Private keys

6.1.  Encryption

   Applications MUST support the encrypted PEM files in the form based
   on [RFC1423] which is commonly used by historical versions of
   OpenSSL, with at least the DES-EDE3-CBC, AES-128-CBC and AES-256-CBC
   modes.

   For PKCS#12 [RFC7292] and PKCS#8 [RFC5208] formats, applications MUST
   support reading objects stored with the following encryption methods:

   o  PBES1 pbeWithMD5AndDES-CBC [RFC2898]
   o  PBES1 pbeWithSHA1And3-KeyTripleDES-CBC [RFC7292]
   o  PBES2 AES-128-CBC (OID: 2.16.840.1.101.3.4.1.2) [RFC2898]
   o  PBES2 AES-256-CBC (OID: 2.16.840.1.101.3.4.1.42) [RFC2898]

   The weak methods included in the above list are unfortunately still
   commonplace, and thus clients need to keep supporting them as noted
   in Section 11.  However, applications MAY emit a warning to the user
   when weak (or no) encryption is used, and MAY require an additional
   configuration directive to enable the use of weakly-encrypted and
   unencrypted keys.

   The presence of these algorithms in the list is not in any way to be
   taken as approval for tools to continue creating objects in such
   forms.  Except for a brief discussion in Section 6.3. the creation of
   private keys is outside the scope of this document.

   ...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

> On Tue, 2016-11-22 at 15:49 +0000, David Woodhouse wrote:
>> On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote:
>> > The more interesting part is when it tries to load files it guesses
>> > are raw DER.  It's currently only trying a few chosen content
>> > types,
>> > I'm happy to add more as time goes.  However, I suspect that
>> > nothing
>> > in your test suite will trigger that part.
>>
>> There's a selection of .der and .p12 files there too.
>>
>> Adding non-ASCII passwords and running in different locales (and
>> stress-testing both the old and the new PKCS#12 BMPstring bugs) is
>> still on my TODO list.
>
> Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> can express the same string in various (different) ways, so they cannot
> be directly used as passwords. I have recently added RFC7613
> "normalization" to gnutls, to address the differences.
>
> https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html

Right. You normalise to NFC, yes? That's what my draft recommends. It's a
shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
better than PKCS#8 :)


-- 
dwmw2

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

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote:
> 
> > FWIW I am perfectly content for applications *not* to automatically work
> > with such keys. Making the user jump through extra hoops to use them
> > would be perfectly fine in my book.
> 
> oh I see.  "Users shouldn't care, it should just work"  But only for some 
> keys.
> 
> Part of my I am opposed to guessing.

For me it's the other way round. Magically detecting *that* particular
perfectly valid PKCS#1 RSA key is actually intended for the gem engine
would indeed be guessing. It's a bizarre abuse of PKCS#1 and it doesn't
seem reasonable for anyone to "guess" that without explicit direction.

But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
similar files in both DER and PEM forms, for *those* it makes sense for
applications to Just Work. And it shouldn't really involve "guessing".

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 14:41 +, Peter Sylvester Edelweb wrote:
> 
> An exemple used by the 'gem' engine.
> 
> openssl rsa -in key.pem -text
> Private-Key: (4096 bit)
> modulus:
>     00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f:
>     01:39:34:b7:23:93:5a:61:05:af:b1:04:49:8a:68:
>  
>     95:69:23:21:8d:20:a3:60:e6:e5:65:69:bf:b6:41:
>     f2:40:5c:1d:e3:53:15:90:ff:6d:34:26:45:46:b6:
> 
>    97:f6:7c:f6:0f:5d:d8:59:02:a8:3c:b0:b4:06:2f:
>     c7:b7:c7
> publicExponent: 65537 (0x10001)
> privateExponent: 1 (0x1)
> prime1: 44 (0x2c)
> prime2: 41 (0x29)
> exponent1: 1 (0x1)
> exponent2: 1 (0x1)
> coefficient: 1 (0x1)

Oh, that's special :)

FWIW I am perfectly content for applications *not* to automatically
work with such keys. Making the user jump through extra hoops to use
them would be perfectly fine in my book.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 15:21 +0100, Richard Levitte wrote:
> In message <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016 
> 13:33:45 +, David Woodhouse <dw...@infradead.org> said:
> 
> dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote:
> dwmw2> > > But, what I get from you is "what if a octet stream matches two 
> different
> dwmw2> > > ASN.1 types?  Is that it?
> dwmw2> > 
> dwmw2> > Yes among others.  How do you know it will *never* happen?
> dwmw2> 
> dwmw2> Because if anyone tries to invent yet *another* ASN.1 form for storing
> dwmw2> keys, I am going to personally visit them in the small hours and stick
> dwmw2> a bat up their nightshirt?
> 
> (let's keep the heat down, shall we?)

You're no fun :)

> dwmw2> Hopefully we don't need to add completely new ones; we can use the
> dwmw2> existing PKCS#8 and PKCS#12 containers for new things.
> dwmw2> 
> dwmw2> But even if a new form is invented which is ambiguous with existing
> dwmw2> forms, that's OK too. We don't support 'detection' of that new format
> dwmw2> by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless
> dwmw2> the type is explicitly specified.
> 
> Errr...  Now I'm confused.  Wasn't that (explicit type spec) exactly
> what you didn't want to see, no matter if the file was PEM or raw DER?

I do not want to see it for *reasonable* file types which are in
*common* use¹. Users should be able to just give the filename to the
application, and expect it to Just Work.

Invent something new and esoteric and stupid, and I don't care about
that as much. I might have been joking about visiting you in the small
hours, but I'm *not* going to tell applications that they have to
accept your format automatically, and that they can't make users jump
through hoops to explicitly specify it.

-- 
dwmw2

¹ And I'm still more than happy to take input on which file types meet
  that definition, and adjust my draft accordingly.

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 14:26 +0100, Richard Levitte wrote:
> 
> Quite frankly, that's a though that should go back to David and his
> demand of automatic detection.  If anyone would *ever* create a raw
> DER file holding a tss OCTET STRING, then the file spec *will* have to
> have an indication of what type of content it is.
> If we're thinking in URI terms, I could think of a contraption like
> file:whatever.pem?t=tsskeyblob ...  or dare I say it,
> tpmkey:file=whatever.pem  (David is so going to hate me ;-) ...)

Nah, that's fine. I mean, I hated you already, but I don't hate you any
*more* for that observation.

I don't care about supporting every bizarre esoteric format under the
sun. All I'm after is consistency between applications for the *common*
and *reasonable* file formats.

Right now, if I have a PKCS#12 file with my identity certificate, I can
use that with a *subset* of the applications installed in my system.

If I have a PKCS#8 file, I can use that with a *different* subset of
the applications. A different subset according to whether it's PEM or
DER.

If it's on a PKCS#11 token, I can use that with a *different* subset.

And many applications can be configured to build with a choice of
crypto libraries, so the formats they support will be *different* from
one distribution to another.

It's that mess that I'm trying to fix, but only for the key formats
which are common enough that users have a reasonable expectation that
they'll work.

If some nutter starts writing the TPM_KEY12 OCTET STREAM to a DER file
without even using the TssBlob structure from the TSS spec, I am not
going to lose any sleep over that.

And note that I am actively soliciting input on *what* forms should be
expected to "Just Work" and which are less important.

Perhaps there's a case to be made for ditching DER entirely and
expecting people to use PEM? Or at least expect DER to work only for
PKCS#12, PKCS#8 and PKCS#1?

I'd certainly be OK with never adding any *new* DER forms to the list
of "shall be expected to work", and requiring PEM instead for anything
new. With the caveat that I *am* being led by what's actually out there
in the wild, being issued to users through their corporate and other
PKI infrastructure.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 15:26 -0500, Thomas Francis, Jr. wrote:
> On 11/22/16 2:37 PM, David Woodhouse wrote:
> > And the locale / character set issue is not relevant here. ASN.1 is
> > binary, PEM is ASCII.
> PEM should be ASCII; in practice it is not necessarily ASCII.  There are 
> several products that produce "PEM files" in various EBCDIC character 
> sets.  Other products produce them in ASCII, but then  transfer them 
> with an EBCDIC to ASCII conversion.  And in still others, it's the 
> customer who transfers it manually, converting from EBCDIC to ASCII when 
> the file was ASCII.  These latter two are less common in my limited 
> experience, which is fortunate, because recovering from that is very 
> difficult.
> 
> I've also seen some windows products that will produce "unicode" pem 
> files, which may or may not have a BOM at the beginning, and other 
> products which produce the files with the UTF-8 BOM at the beginning, too.
> 
> While it's easy for me to say these files are malformed, the customer 
> doesn't care.  They have the file; they expect it to work.

Ewww.

I have to confess that I'm mostly disinclined to care. I'll just go
back to your first sentence cited above, and "clarify" my original
statement to "the PEM that we *support* is ASCII".

But if people *really* expect it to work... would you seriously suggest
that this abomination (at least the EBCDIC and UTF-16+BOM variants) is
something that applications ought to support automatically? If so,
perhaps you'd be arguing that I should update my draft at
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html to
mandate support for it? I suppose checking for a BOM and eating UTF-16
really *isn't* that complicated for an application.

As things stand I suppose I should at least mention it, but I'm
inclined to say that applications MAY support these variants but are
not required to.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
> 
> Right...
> 
> But then, embedding everything in an OCTET STRING isn't exactly a
> novel idea either.  How do we discern a DER encoded TSS KEY BLOB from
> whatever else that had the same "novel" idea? An OCTET STRING is an
> OCTET STRING is an OCTET STRING...  See the dragons hovering over
> there? ;-)

We don't. Crap like that is auto-detected in PEM form only. And yes, it
*really* should have used the TssBlob structure, not just the OCTET
STRING.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
> 
> 
> dwmw2> So maybe it's just "content types" that we have handlers for, each with
> dwmw2> an optional PEM tag for matching, *and* an optional match function
> dwmw2> which is given the parsed ASN.1 and checks if it's a match.
> 
> I'm not sure what you mean with a match function...  but going off on
> a limb, how about a reference to an OpenSSL style ASN1 description?
> So basically, for an imaginary TSS KEY BLOB (one that actually would
> use that TssBlob definition we talked about earlier), these three
> items would be specified:
> 
>     "TSS KEY BLOB",
>     ASN1_ITEM_rptr(TSS_BLOB),   /* TSS_BLOB ASN1 stuff defined in engine */
>     handler /* Essentially a d2i function */
> 
> Or did you mean that the matching would also involve checking the
> contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
> if they correspond to your structures?  If that's what you mean, my
> gut feeling tells me - and I haven't had my morning coffee yet - we're
> now moving into a territory where I fully expect dragons...  not to
> mention the worries Rich expressed.

Oh $DEITY no,  not looking in the contents of the OCTET_STRING.
Basically I'm thinking of doing precisely what d2i_AutoPrivateKey()
already does, just with expanded coverage and slightly less hard-coded
stuff.

The "match" part there is a little simplistic; we basically parse the
ASN.1 into a STACK_OF(ASN1_TYPE), then 

 if (sk_ASN1_TYPE_num(inkey) == 6)
   /* it's DSA in OpenSSL's format */
 if (sk_ASN1_TYPE_num(inkey) == 4)
   /* it's ECDSA according to RFC5915 */
 if (sk_ASN1_TYPE_num(unkey) == 3)
   /* Unencrypted PKCS#8 */

... etc.

Those checks could possibly stand to be a *little* more discerning, and
 each one might live in a specific format-handler's "ASN.1 match"
function. But that's the general idea. And we *do* already have the
"decide, then parse" model that Rich was talking about.

And yes, if we're going to make the checks slightly more discerning
then instead of just counting the items in the sequence, we could see
if it matches the ASN.1 description. And as you say, it doesn't have to
be a match *function* for each handler; just the ASN.1 description. 

Doing it like that would prevent any implementations (like the one in
the TPM engine) from being *tempted* to go prodding around in the
contents of OCTET STRINGs. Which is probably a feature :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-23 at 09:39 +0100, Tomas Mraz wrote:
> 
> I also would not be too much worried - the API call should not be
> completely universal - the application should know whether it is
> loading a certificate or private key. It should just be able to use a
> single call to load a certificate in PEM, DER, or whatever other
> possible data format. The same for private keys, etc.

Well, except in the case where the application asks to use a PKCS#12
file as the identity. In which case you want to load cert, key, and
supporting cert chain all from the same place.

And you often have a PEM file which contains both the certificate and
the private key.

But yes, generally you *know* what you're looking for.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
> 
> Actually, I agree with this, and that goes along with how our PEM
> routines work (specifically, PEM_X509_INFO_read_bio()), it just
> treats the data as an octet string and hands it down to a d2i routine
> of choice, with a pointer to where to place the result.
> 
> It's not very hard to imagine adding the possibility for external
> handlers for specific PEM content types, which could be handed an
> octet string and a pointer to a X509_INFO (which is the structure used
> to collect the data in), or something like that (I can also imagine
> having one separate handler for each type of data that can be
> returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
> and so on and so forth).  That would make it possible for an engine to
> declare its own handler during the binding call, along with all other
> information it feeds back to libcrypto.

Yeah, something like that.

It's worth noting that the 'PEM content types' are just the same as the
'DER content types'. It's just that if you have a PEM header, you know
precisely *which* DER content type you have after base64-decoding (and
decryption in some cases), and you don't have to do what
d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

So maybe it's just "content types" that we have handlers for, each with
an optional PEM tag for matching, *and* an optional match function
which is given the parsed ASN.1 and checks if it's a match.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote:
> > That's not the proposal.  The proposal is to use PEM form because we can
> > make it uniquely self describing using the guard tags which obviates the
> > problem above.
> 
> Well that's what you want.  David wants more than that :)

S'true :)

> > On the larger issue of non-self describing formats like ASN.1: if your 
> > theory
> > that there's a security hole by allowing opportunistic format detection is
> > correct, simply making the user specify is palming our bug off on to the 
> > user
> > and abdicating responsibility because now when they're tricked into an
> > exploit they can be blamed not openssl.  If such a bug exists, doing
> > opportunistic format detection the better guarantor of overall system
> > security because if such a bug is found, it would have to be fixed within
> > openssl to everyone's benefit.
> 
> We differ.

We do. I think James put it well though, when he talked of "palming our
bug off onto the user and abdicating responsibility". The library
doesn't get to sit in its ivory tower of perfection; you are
responsible for the API you inflict on users and how they actually
*use* it.

And besides, even if we force applications to iterate over the possible
formats for themselves, they aren't going to have a bug *there*. Any
bug will be in our parser for one specific format or another. We didn't
even *save* our reputation by forcing the application authors to jump
through hoops.

And more to the point, you already *do* this, in d2i_AutoPrivateKey().
It's just that you only handle *some* of the known key formats, so the
application has to explicitly try the others. What's being proposed
here is merely that we fix that up to have full coverage — not a
radical new approach at all.

Oh, and that we automatically distinguish between PEM and DER forms,
but *that* much is fairly trivial and safe.

And the locale / character set issue is not relevant here. ASN.1 is
binary, PEM is ASCII.

When we come to talk about passwords, *sure* we can look at character
sets. But that is a somewhat orthogonal issue.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 18:46 +0100, Richard Levitte wrote:
> In message 
> <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on 
> Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich"  said:
> 
> rsalz> > The more interesting part is when it tries to load files it guesses 
> are raw DER.
> rsalz> 
> rsalz> And this part worries me.  I do not think a "security library" should 
> be guessing.
> 
> It does this by trying to interpret the blob against known ASN.1
> definitions, and will only succeed when there's a complete match.  I'm
> not terribly worried...

And even if you were, you should be *more* worried about making
*applications* do it for themselves :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> 
> dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is
> dwmw2> redundant anyway.
> 
> Oh!  Ok, that makes things much simpler (at least in a way)

Kind of. But then again, there's an argument that it was none of your
business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to the
TPM engine and after that you really don't care about what's in it.

Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
files (no ASN.1 at all). For some reason it didn't use the TssBlob
object type, although perhaps it should.

When I started looking at it, I used the -BEGIN TSS KEY BLOB-
for an OCTET STRING containing *just* that the code had previously been
writing into its binary files.

If I'd been aware of the TssBlob definition at that time, I suppose I
would have used it instead of just the OCTET STRING. But I didn't.

If we write an I-D covering the TPM keys, perhaps the PEM contents
should be permitted to be *either* a raw OCTET STRING with the key
blob, OR a TssBlob object. Or maybe we should add a
BEGIN TSS BLOB- (without 'KEY' in it) instead?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 17:14 +0100, Richard Levitte wrote:
> 
> I'm sorry, I have obviously had you a bit confused.  What I'm
> currently interested in is decoding the content of a 'TSS KEY BLOB'
> PEM file, and I assume that's a TssBlob type, yeah?

No, it's not. (Sorry!)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 07:44 -0800, James Bottomley wrote:
> 
> > I'm just having a look at the spec (page 151 in
> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
> > a_A-final.pdf), and am a bit confused by the TssBlobType type.  Which 
> > is it in practice, an ENUMERATED or an INTEGER?
> 
> It's actually here:
> 
> http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
> 
> It's around page 101, section 10.3 the TPM_KEY12 structure.  That tells
> you what to encrypt and how to construct the encrypted part of the
> blob.  It refers to other structures, so you end up doing a bit of a
> pointer chase through the document.

The TPM_KEY12 structure is what's in the OCTET STRING (that I just
showed). But I believe we're looking at the ASN.1 on page 151 (§3.23
"Portable Data") of the TSS spec:

TssBlobType ::= ENUMERATED
{
Key-Blob (1),-- TCPA_KEY as returned from TPM
PubKey-Blob (2), -- TCPA_PUBKEY as returned from TPM
MigKey-Blob (3), -- TCPA_KEY as return from the TSP 
Tspi_Key_CreateMigrationBlob
In dedicated mode (see the command for details)
SealedData-Blob (4),   -- TCPA_STORED_DATA as returned from TPM
...
}

TssBlobType ::= INTEGER
TssBlob ::= SEQUENCE
{
StructVersion INTEGER, -- Version of this structure; at the moment 1
BlobType TssBlobType,  -- Type of Blob; see enum
BlobLength INTEGER,-- Length of Blob
Blob OCTET STRING  -- Blob as returned from TPM (no ASN1 encoding)
}

To my knowledge nothing actually *implements* this TssBlob. Those PEM
files (like the one I just showed) only contain the OCTET STRING.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 
> 11:57:42 +, David Woodhouse <dw...@infradead.org> said:
> 
> dwmw2> Besides, it requires files in the form described by the Portable Data
> dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
> dwmw2> (which is mostly redundant as in this case we're always talking about
> dwmw2> key blobs), the blob length (which is entirely redundant) and then the
> dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually
> dwmw2> creates such files.
> 
> I'm just having a look at the spec (page 151 in
> http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
> and am a bit confused by the TssBlobType type.  Which is it in
> practice, an ENUMERATED or an INTEGER?

In practice, it doesn't get used at all. The object encoded with
-BEGIN TSS KEY BLOB- and used by both the OpenSSL TPM ENGINE
and by GnuTLS is not the TssBlob object that you're looking at.

It is *only* the OCTET STRING of the blob itself. Everything else is
redundant anyway.

$ openssl asn1parse -i -in tpmkey.pem -inform pem
0:d=0  hl=4 l= 559 prim: OCTET STRING  [HEX
DUMP]:0101001500060100020003000C0802000
00100D6791E892D6B93830F026C6C66B365A0B61B3CBB5B36EA1A13
C67111D49711719E665B5EBAAB5F9CB04D7CC87C78DE56700CD6A8F9B94C92DF029983F
2DA8883841090CEAACD53453516843FEF6689AC5E7D8102B85141B86B2F0E8C99124A70
90C5FB35A902D672E56D2BC2654317DCF578692B8CC441E08E3CCEF8CE86219822250CA
3A23A70EF69B3A092B3DFA70F049B712B885B8EA576C9F3F4E54107DB8F8D678CCF376D
9299BB47013318999FA8099180815D99F90646588508AACF7527E7A6D38C6C53B78C9BA
6F693069F2906B82E5500D5209489E48C29A4B487564AC64CED3FC61D88EF0C27C0E5EE
5AFEB861E3B104F8FCABDBE07DBE4FE42D2B010091175251D67BE97DB4A4F48EF5D
515E9ED64287BF2DFCCCDD6E6791AADC7E6752F2A2DCD3CBC29AB8660947B78C1F15C30
26369AC4A6B5434996CDB3CA659A2A2F48BE26B7E3C5AEBD75A6B6BCB376650138DCAD0
00E46BD94139A9DD596355C0469463E0E7D68C9997724EC7CFACDDC8EFA3C81045F5076
284BA2CA0B935DCFC28793D1BC9E8D2F4F141788B92DA93D3B370C8A24AFF59DEAAC81F
5A96C2299CBA74AA651E0AF92122B4F7524D08027DA71EDB191B115722AEB7F97817346
4484778FF88BC56815420791D7F9FB1ADD781D979A85D69F31970F228A6A12C6FD4FC3C
AF7A9F8F933818D436C5552D7B60A1E48CDEC7E38FC452A359C6E1609EC

$ openconnect -c cert.pem -k tpmkey.pem auth.startssl.com -v
POST https://auth.startssl.com/
Attempting to connect to server 104.192.110.244:443
Connected to 104.192.110.244:443
Using certificate file cert.pem
Using private key file tpmkey.pem
TPM sign function called for 35 bytes.
Using client certificate '192.168.123.1'
TPM sign function called for 51 bytes.
SSL negotiation with auth.startssl.com
...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote:
> In message 
>  on 
> Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich"  said:
> 
> rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
> rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
> rsalz> 
> rsalz> I disagree with this approach, but that's just my opinion.  I am 
> worried about "keep trying something until it works" because you'll get 
> strange errors you can't decode, 'only allow N tries' devices will lock you 
> out, and the order in which you try things could result in needless long 
> delays.
> rsalz> 
> rsalz> But don't let that stop you.
> 
> I *think* the guessing part is just about the step of loading the file
> content and transparently understanding what type of content it is.
> That's basically looking at a bunch of bytes and recognising it for
> what it is.  When that's done, the trial and error phase is over, and
> for stuff that libcrypto has support for, libcrypto will be able to
> act, deterministically.
> 
> From the application point of view, this would be just one call, but
> we are talking OpenSSL internals now, aren't we?
> 
> David, correct me if I got you wrong.

You have it entirely correct. Rich has a valid concern for the general
case, but it doesn't apply *here* because we're just talking about
interpreting files. No hardware token is going to get upset and lock
you out, just because you actually look inside the file and work out
what type it is, then treat it as that — instead of forcing the
*application* to look inside the file first, then invoke the crypto
library differently for each type of file (or URI), as shown at 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c#l827

Basically, for every line in that load_certificate() function and the
subfunctions it calls, I hate you :)

When it comes to talking to real hardware, Rich is absolutely right.
You don't just keep trying there. So if you look at the 'Locating
objects in PKCS#11' section of my best practice draft¹ you'll see that
you're only supposed to log into a given token if you *know* that's the
one you need — either because you're looking for a key and you've
already found the corresponding certificate in that token without
having to log in, or because the PKCS#11 URI actually *specified* the
token unambiguously. But that's a separate issue.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.8

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote:
> The more interesting part is when it tries to load files it guesses
> are raw DER.  It's currently only trying a few chosen content types,
> I'm happy to add more as time goes.  However, I suspect that nothing
> in your test suite will trigger that part.

There's a selection of .der and .p12 files there too.

Adding non-ASCII passwords and running in different locales (and
stress-testing both the old and the new PKCS#12 BMPstring bugs) is
still on my TODO list.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
> 
> Just let me shamelessly mention my STORE effort again ;-)
> Among others, it does attempt to solve that very problem (in the
> 'file' scheme handler).

Neat. Note that I have a ready-made test suite for you in OpenConnect:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

For every one of the key files therein, does your current
implementation work? :)

(Yeah, I need to sort out the tpm emulator in the test environment,
then add some -BEGIN TSS KEY BLOB- files too :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote:
> In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 
> 13:12:14 +, David Woodhouse <dw...@infradead.org> said:
> 
> dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> dwmw2> > 
> dwmw2> > Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
> dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever
> dwmw2> > way it sees fit.  For me as a user, it's just a string.  For all I
> dwmw2> > care, the URI could just as well be 
> 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not
> dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a
> dwmw2> > file /foo/bar/key.pem.  Maybe I misunderstand what you're after...
> dwmw2> 
> dwmw2> Where files are involved, I do not want the application to be told:
> dwmw2>  pkcs8:/foo/bar/key
> dwmw2>  pkcs1:/foo/bar/key
> dwmw2>  pkcs12:/foo/bar/key or
> dwmw2>  tpmkey:/foo/bar/key
> dwmw2> 
> dwmw2> I only want the application to be told "/foo/bar/key"
> 
> Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM
> type would be a way to go, wouldn't you say?  That, or add functionality
> to have PEM content handlers added dynamically, one for each PEM
> content type.
> Just please, that "pass the BIO" hack...  sorry, I'm not a supporter.

I think the number of "new" PEM formats is going to be vanishingly
small, and it's OK to have knowledge of them hard-coded in OpenSSL
rather than having a fully dynamic mechanism.

Doing it dynamically would be painful — either the appropriate engine
needs to be loaded already, or we need a mapping from PEM 'BEGIN'
string to the engine name somehow.

> dwmw2> It should work out what the contents are for *itself*. Whether they be
> dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
> 
> Yeah, got it...  my thinking was on a tachnical level, that
> 'whatever.pem' would have to be handled by OpenSSL itself (or in URI
> terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem'
> would be handled by the 'tpmkey' scheme handler, which is a different
> story to me.

Yes, they end up being routed to the same engine via entirely different
paths. Both need resolving, and we need not to conflate the two.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> 
> Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
> parameter that the 'tpmkey' handler is free to interpret in whatever
> way it sees fit.  For me as a user, it's just a string.  For all I
> care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> That doesn't say anything about the contents of /foo/bar/key.pem, not
> more than file:/foo/bar/key.pem does, or even if there actually is a
> file /foo/bar/key.pem.  Maybe I misunderstand what you're after...

Where files are involved, I do not want the application to be told:
 pkcs8:/foo/bar/key
 pkcs1:/foo/bar/key
 pkcs12:/foo/bar/key or
 tpmkey:/foo/bar/key

I only want the application to be told "/foo/bar/key"

It should work out what the contents are for *itself*. Whether they be
PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

And if the string it's given *isn't* a filename but is instead a
PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
Work too.

User pass string identifying key. Application Just Work™. dwmw2 happy.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote:
> > would much rather have seen a patch where OpenSSL's PEM module is
> > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, 
> > securing
> 
> Yes, that would be much more consistent with the existing OpenSSL
> code which -- like it or not -- works that way.

Yeah. Although I'd note that the OpenSSL code only works that way for
PEM files. I really want to make it work the same way for DER files
too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
have to call different functions for PEM vs. DER files anyway.

> > My vote goes to a URI based spec rather than bastardising PEM files.
> 
> Sure, if you can figure out which URI scheme to use; there are many
> of them. :)

For TPM I am not aware of any scheme other than the one set out in
https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-11-22 at 13:48 +0100, Richard Levitte wrote:
> Mm...  I'm not sure I agree with the method, passing a BIO for the
> key_id.  I would much rather have seen a patch where OpenSSL's PEM
> module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
> from it, securing it somehow (since key_id is expected to be be NUL
> terminated) and pass that to the engine.

Agreed.

> My vote goes to a URI based spec rather than bastardising PEM files.
> I understand this kinda throws years of developmemt out the window,
> but there you have it.

I think we need both. We need the URI for the keys stored *in* the TPM
where we just need to reference them. And we need (non-bastardised) PEM
files with TPM-wrapped key blobs. The latter is what the engine
supports right now (by filename only).


-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
>     -BEGIN PRIVATE KEY-
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?

Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
and had the "tpm" engine automatically loaded on demand. It needs to be
 something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 1/2] engine: add new flag based method for loading engine keys

[David Woodhouse]

On Thu, 2016-11-17 at 09:33 +0200, Roumen Petrov wrote:
> David Woodhouse wrote:
> > > The assumption in all the current engine code is that key_id can be
> > > passed as something like a file name.
> 
> This is mostly documentation issue.
> Usually OpenSSL man pages use filename for , but actually it is 
> just a string and engine is responsible how to process

Right. In engine_pkcs11 it's a RFC7512 PKCS#11 URI and not a filename.

> > >   There are some new users that
> > > actually want to pass a BIO, so add a new load_key method for
> > > engines
> > > that takes a flag value.
> 
> Engine could use some URN formats for . For instance if  
> starts with file:/ engile could try to load from filesystem.

Note that GnuTLS has a URN format for keys stored in the TPM. See
output of 'tpmtool --list' for example. The TPM engine should probably
accept those.

But this doesn't help with the case where we *have* the actual
(wrapped) key data in memory already — unless you pass in a string
which is a base64-encoded form of that, which is kind of horrid.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 1/2] engine: add new flag based method for loading engine keys

[David Woodhouse]

> The assumption in all the current engine code is that key_id can be
> passed as something like a file name.  There are some new users that
> actually want to pass a BIO, so add a new load_key method for engines
> that takes a flag value.  The first defined flag is
> ENGINE_LOAD_KEY_FLAG_BIO which means that the key_id is actually a bio
> pointer.

I like that this also fixes the UI callback horridness discussed at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/b8d39711:/openssl.c#l423

I like it even more that I can completely remove all mention of the TPM
and the special case to load the engine, and just rely on OpenSSL to Do
The Right Thing when I feed it a PEM file containing -BEGIN TSS KEY
BLOB-, just like GnuTLS does.

-- 
dwmw2

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

Re: [openssl-dev] DTLS encrypt-then-mac

[David Woodhouse]

On Thu, 2016-10-13 at 23:48 +0100, Matt Caswell wrote:
> 
> > Any dissenting opinions?
> 
> Not from me. It's broken. Lets fix it.

Thanks. https://github.com/openssl/openssl/pull/1705 updated accordingly.

With that fixed, I think https://github.com/openssl/openssl/pull/1666
is now ready to be merged too (it contains the fixes from #1705, which
it depends on).

The only bit I wasn't sure about in #1666 was the addition of the DTLS
cipher tests to ssl_test_old — which is redundant now I've written a
completely new test to do an MTU torture test on every cipher suite
(both with an without EtM, for CBC suites). So I took it out.

But I've submitted that part separately anyway, since part of it might
be useful — in order for the test recipe to *get* the list of DTLS
ciphersuites, I had to make 'openssl ciphers DTLSv1' work. Which might
be worth keeping, although it wants careful review:
https://github.com/openssl/openssl/pull/1710

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

On Wed, 2016-10-05 at 20:46 +0100, Matt Caswell wrote:
> 
> Or even 1.1.1! Why don't you pull this together into a github PR?

https://github.com/openssl/openssl/pull/1666

Not complete, but good enough for you to heckle at the approach, and
it'll be a whole lot simpler for someone with more clue to finish
filling in my SSL_CIPHER_get_overhead() function. I'm all done reading
ciphersuite RFCs for tonigh^Wthis morning.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote:
> Hwell its not constant even by cipher. It depends on the
> transport (IPv6 has a bigger overhead than IPv4).

That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not
included in d1->mtu (SSL_set_mtu()).

Even when we let DTLS autodetect by using BIO_CTRL_DGRAM_QUERY_MTU, it
gets a value without the (assumed) IP/UDP overhead, which goes straight
into d1->mtu.

The "link MTU" thing is purely a special case for application
convenience. AFAICT we only *ever* use it by subtracting the
BIO_CTRL_DGRAM_GET_MTU_OVERHEAD value (which again assumes UDP not
SCTP) and then dealing with d1->mtu thereafter.

So let's forget all about the "link MTU" and the IP/UDP overhead for
now. They are an orthogonal issue.

> So why not:
> 
> DTLS_get_data_mtu(SSL *s)

Yeah. OK. And I don't think we need a DTLS_set_data_mtu(). If the
application knows the largest data payload it'll ever send... who cares
about telling OpenSSL the MTU? Just call SSL_set_mtu(s, 65536) and then
send what you like.

> I've not thought about it in great detail, but it looks ok at first
> glance.

Thanks. I'll use that as a basis for DTLS_get_data_mtu() then.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

On Wed, 2016-10-05 at 21:31 +0100, Matt Caswell wrote:
> 
> 
> On 05/10/16 15:37, David Woodhouse wrote:
> >   DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu);
> > 
> >   /* We already set the link MTU, but hopefully by the time we
> >    * finish it, this function will be better at working out the
> >    * actual tunnel MTU than OpenSSL is. So do that too... */
> >   SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu);
> 
> This is pointless. The link mtu setting will take precedence.

Hm, thanks. It's also wrong. There are *three* MTU values, and I had
conflated them.

Firstly there is the the link MTU (d1->link_mtu, e.g. 1500).

Secondly there is the DTLS record MTU without the IP/UDP overhead
(d1->mtu, e.g. 1472).

Finally there's the one I need to find, the data payload MTU
(with AES128-GCM e.g. 1434).

The code you saw was using DTLS_set_link_mtu(1472) where it should be
using SSL_set_mtu(1472).

I shouldn't be calling DTLS_set_link_mtu() at all.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

>
>
> On 05/10/16 15:37, David Woodhouse wrote:
>> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote:
>>> How's this for a start...
>>
>> Now I think I have it right for CCM too, although having to use
>> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305...
>> and then maybe I can stop worrying about new modes and ciphersuites
>> because those won't be added in OpenSSL 1.1 and we can get OpenSSL do
>> to this for itself before 1.2? :)
>
> Or even 1.1.1! Why don't you pull this together into a github PR?

Sure. Any thoughts on what you want it to look like? Not just
SSL_CIPHER_get_overhead() because it'seems not constant -- you have to
account for blocksize rounding and padding in CBC ciphers. So just
SSL_CIPHER_get_data_mtu(int link_mtu)?

Or are there other use cases we want it for, and we *should* try returning
a full set of three "add this, round up to this, add this" integers?

As for the actual numbers... am I on the right track so far?

-- 
dwmw2

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

Re: [openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote:
> How's this for a start...

Now I think I have it right for CCM too, although having to use
strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305...
and then maybe I can stop worrying about new modes and ciphersuites
because those won't be added in OpenSSL 1.1 and we can get OpenSSL do
to this for itself before 1.2? :)

/* sets the DTLS MTU and returns the actual tunnel MTU */
unsigned dtls_set_mtu(struct openconnect_info *vpninfo, unsigned mtu)
{
int tun_mtu;
int ivlen, maclen, blocksize = 1, pad = 0;

#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
/* OpenSSL <= 1.0.2 only supports CBC ciphers with PSK */
ivlen = 
EVP_CIPHER_iv_length(EVP_CIPHER_CTX_cipher(vpninfo->dtls_ssl->enc_write_ctx));
maclen = EVP_MD_CTX_size(vpninfo->dtls_ssl->write_hash);
blocksize = ivlen;
pad = 1;
#else
/* Now it gets more fun... */
const SSL_CIPHER *s_ciph = SSL_get_current_cipher(vpninfo->dtls_ssl);
const EVP_CIPHER *e_ciph;
const EVP_MD *e_md;
char wtf[128];

e_ciph = EVP_get_cipherbynid(SSL_CIPHER_get_cipher_nid(s_ciph));

switch (EVP_CIPHER_mode(e_ciph)) {
case EVP_CIPH_GCM_MODE:
ivlen = EVP_GCM_TLS_EXPLICIT_IV_LEN;
maclen = EVP_GCM_TLS_TAG_LEN;
blocksize = 1;
pad = 0;
break;

case EVP_CIPH_CCM_MODE:
ivlen = EVP_CCM_TLS_EXPLICIT_IV_LEN;
SSL_CIPHER_description(s_ciph, wtf, sizeof(wtf));
if (strstr(wtf, "CCM8"))
maclen = 8;
else
maclen = 16;
blocksize = 1;
pad = 0;
break;

case EVP_CIPH_CBC_MODE:
e_md = EVP_get_digestbynid(SSL_CIPHER_get_digest_nid(s_ciph));
blocksize = EVP_CIPHER_block_size(e_ciph);
ivlen = EVP_CIPHER_iv_length(e_ciph);
pad = 1;
maclen = EVP_MD_size(e_md);
break;

case EVP_CIPH_STREAM_CIPHER:
/* Seen with PSK-CHACHA20-POLY1305 */
default:
printf("wtf mode %d\n", EVP_CIPHER_mode(e_ciph));
// XXX
;
}
#endif


/* Take off the explicit IV and the MAC (XXX: overflow!) */
printf("iv %d mac %d blk %d\n", ivlen, maclen, blocksize);
tun_mtu = mtu - DTLS1_RT_HEADER_LENGTH - ivlen - maclen;
/* For block cipher modes round down to blocksize */
printf("tun %d & 0x%x == %d\n", tun_mtu, ~(blocksize-1), tun_mtu & 
(~(blocksize-1)));
tun_mtu -= tun_mtu % blocksize;
/* ... and CBC modes require at least one byte to indicate padding 
length */
tun_mtu -= pad;

DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu);

/* We already set the link MTU, but hopefully by the time we
 * finish it, this function will be better at working out the
 * actual tunnel MTU than OpenSSL is. So do that too... */
SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu);

return tun_mtu;
}

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

On Wed, 2016-10-05 at 10:04 +0100, Matt Caswell wrote:
> 
> > For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract:
> >  - 20 bytes for a Legacy IP header.
> >  - 8 bytes for UDP header.
> >  - 13 bytes for DTLS header
> >  - 16 bytes for the hash
> >  - 8 bytes for nonce
> > 
> > ... and be left with 1435 bytes.
> > 
> > In GnuTLS this is fairly trivial; I call gnutls_dtls_set_mtu() followed
> > by gnutls_dtls_get_data_mtu().
> > 
> > How do I do it in OpenSSL? Do I need to build a big table of the
> > overhead of all ciphers and calculate it for myself?
> 
> I don't think there is a simple way to do this.
> 
> You can ask the underlying BIO to give you the transport protocol
> overhead using BIO_dgram_get_mtu_overhead(). DTLS1_RT_HEADER_LENGTH
> gives you the DTLS header value. You can find out features of the
> ciphersuite using SSL_get_cipher().

Right, it's the "features of the ciphersuite" which is the fun part. 

Specifically, the size of the nonce/IV, the size of the hash, and the
block size for block ciphers where we need to round up the sizes.

SSL_get_cipher() gives me a string, and I could implement a big lookup
table — but we recently moved to using PSK and "proper" DTLS
negotiation precisely to *avoid* having to have ciphersuite-specific
knowledge in the client.

How's this for a start... how is it that the more I work on this stuff,
the more I realise how *utterly* clueless about it I am? :)

Specific questions I *know* I need to focus on include which *other*
modes other than CBC/CCM/GCM I might need to handle, and fairly much
everything about the CCM case.

Can we add something to OpenSSL 1.2 which means I don't need to keep
doing this in the application, please?

/* sets the DTLS MTU and returns the actual tunnel MTU */
unsigned dtls_set_mtu(struct openconnect_info *vpninfo, unsigned mtu)
{
int tun_mtu;
int ivlen, maclen, blocksize = 1, pad = 0;

#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
/* OpenSSL <= 1.0.2 only supports CBC ciphers with PSK */
ivlen = 
EVP_CIPHER_iv_length(EVP_CIPHER_CTX_cipher(vpninfo->dtls_ssl->enc_write_ctx));
maclen = EVP_MD_CTX_size(vpninfo->dtls_ssl->write_hash);
blocksize = ivlen;
pad = 1;
#else
/* Now it gets more fun... */
const SSL_CIPHER *s_ciph = SSL_get_current_cipher(vpninfo->dtls_ssl);
const EVP_CIPHER *e_ciph;
const EVP_MD *e_md;

e_ciph = EVP_get_cipherbynid(SSL_CIPHER_get_cipher_nid(s_ciph));

switch (EVP_CIPHER_mode(e_ciph)) {
case EVP_CIPH_GCM_MODE:
ivlen = EVP_GCM_TLS_EXPLICIT_IV_LEN;
maclen = EVP_GCM_TLS_TAG_LEN;
blocksize = 1;
pad = 0;
break;

case EVP_CIPH_CCM_MODE:
ivlen = EVP_CCM_TLS_EXPLICIT_IV_LEN;
/* What is the tag size for CCM? */
maclen = blocksize = EVP_CIPHER_block_size(e_ciph);
/* Padding same as CBC? */
pad = 1;
break;

case EVP_CIPH_CBC_MODE:
e_md = EVP_get_digestbynid(SSL_CIPHER_get_digest_nid(s_ciph));
blocksize = EVP_CIPHER_block_size(e_ciph);
ivlen = EVP_CIPHER_iv_length(e_ciph);
pad = 1;
maclen = EVP_MD_size(e_md);
break;

default:
// XXX
;
}
#endif


/* Take off the explicit IV and the MAC (XXX: overflow!) */
printf("iv %d mac %d blk %d\n", ivlen, maclen, blocksize);
tun_mtu = mtu - DTLS1_RT_HEADER_LENGTH - ivlen - maclen;
/* For block cipher modes round down to blocksize */
printf("tun %d & 0x%x == %d\n", tun_mtu, ~(blocksize-1), tun_mtu & 
(~(blocksize-1)));
tun_mtu &= ~(blocksize-1);
/* ... and CBC modes require at least one byte to indicate padding 
length */
tun_mtu -= pad;

DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu);

/* We already set the link MTU, but hopefully by the time we
 * finish it, this function will be better at working out the
 * actual tunnel MTU than OpenSSL is. So do that too... */
SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu);

return tun_mtu;
}

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

[David Woodhouse]

On Wed, 2016-10-05 at 09:08 +, Salz, Rich via RT wrote:
> I think you are reading too much into Viktor's words.  From my
> perspective he was proposing a work-around, nothing more.

OK, that makes sense. 

> Yeah, what we did is sub-optimal.  Not the first time, won't be the
> last :)

:)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

[David Woodhouse]

On Wed, 2016-10-05 at 08:03 +, Salz, Rich wrote:
> 
> > And the *only* justification for the fact that bug continues to exist — and 
> > in
> > fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it — is for
> > backward compatibility with older releases.
> > 
> > So how can we be so sanguine about the above failure report?
> 
> Because backward compatibility is very important.

Absolutely.

But Sergey is reporting a *failure* in backwards compatibility, and
Viktor's response seemed remarkably sanguine about that...

I understand "let's not fix the bugs because backwards compatibility",
although I wish we'd done it without introducing a *new* bug in the
process.

But RT#4697 makes it look like we lost backward compatibility *anyway*,
but *without* fixing it to do the right thing. Giving us the worst of
both worlds :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

[David Woodhouse via RT]

On Wed, 2016-10-05 at 07:05 +, Sergey G Brazhnikov via RT wrote:
> 
> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb only)

What files? Do you mean private key files? If so, in what form?
Encrypted PEM, PKCS#8, PKCS#12? All could have different character set
behaviour. I'm assuming the passphrase has non-ASCII characters in it?

What is the local character set (chcp) when the file is created, and
when it is used? You're doing this on the same machine?

Can you show an example?

-- 
dwmw2
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

[David Woodhouse]

On Wed, 2016-10-05 at 07:05 +, Sergey G Brazhnikov via RT wrote:
> 
> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb only)

What files? Do you mean private key files? If so, in what form?
Encrypted PEM, PKCS#8, PKCS#12? All could have different character set
behaviour. I'm assuming the passphrase has non-ASCII characters in it?

What is the local character set (chcp) when the file is created, and
when it is used? You're doing this on the same machine?

Can you show an example?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

[David Woodhouse]

On Wed, 2016-10-05 at 07:17 +, Viktor Dukhovni wrote:
> On Wed, Oct 05, 2016 at 07:05:06AM +, Sergey G Brazhnikov via RT wrote:
> 
> > 
> > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> > decrypted with previous releases and vice versa.
> > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> > 0.9.8(cast5-cfb only)
> > 
> > All built without errors, passed all tests.
> > Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015.
> 
> Especially on Windows systems you have to be mindful of the
> character-set encoding of the passphrase.
> 
> Try setting OPENSSL_WIN32_UTF8=1 in your environment and see if
> that helps.  For interoperable password-based encryption the password
> character-set needs to be standard.

Wait a minute.

Yes, the character-set needs to be standard. It is a bug in OpenSSL
that we don't convert from the locale character set *to* something
standard, before key derivation.

And the *only* justification for the fact that bug continues to exist —
and in fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing
it — is for backward compatibility with older releases.

So how can we be so sanguine about the above failure report?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Calculating DTLS payload MTU

[David Woodhouse]

I have the link MTU (typically 1500 bytes), and a DTLS session is
established.

I call DTLS_set_link_mtu() to set the link MTU.

I need to know the DTLS data MTU — the maximum payload size, which
depends on the cipher in use.

For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract:
 - 20 bytes for a Legacy IP header.
 - 8 bytes for UDP header.
 - 13 bytes for DTLS header
 - 16 bytes for the hash
 - 8 bytes for nonce

... and be left with 1435 bytes.

In GnuTLS this is fairly trivial; I call gnutls_dtls_set_mtu() followed
by gnutls_dtls_get_data_mtu().

How do I do it in OpenSSL? Do I need to build a big table of the
overhead of all ciphers and calculate it for myself?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL F2F

[David Woodhouse]

On Mon, 2016-10-03 at 14:52 +, Salz, Rich wrote:
> Sorry, we didn’t think to put this out earlier…
>  
> The OpenSSL dev team is having a face-to-face meeting this week in
> Berlin, co-located with LinuxCon.  If you’re in the area, feel free
> to stop by. In particular, on Tuesday from 16:50-17:40 – “Members of
> the openssl development team will be available to help with porting
> applications to 1.1.0, help guide how people can contribute to the
> project, and be available to discuss other technical issues.
> Downstream distributions and embedded applications developers should
> also stop by to introduce themselves”
>  
> If you’re not available during that time, but want to chat, please
> let us know.

Hm, not *quite* enough time for me to get a flight to Berlin today...
and I'd have a three-year-old in tow.

I would dearly have loved to make it, because I'd like to get some more
detailed consensus on adding PKCS#11 support.

In the past we've provisionally agreed on "let's do it after 1.1"... so
now we should be looking at a slightly more detailed plan. I *can* just
start throwing patches over the wall, but a high-level consensus on the
architecture might have been useful. And we're all busy enough that it
just seems easier to do it face-to-face while we're in the same time
zone.

I would also love to get feedback on, and do some proselytism for,
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
 
-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[David Woodhouse]

On Mon, 2016-09-26 at 10:35 +, OpenSSL wrote:

> Content-Type: text/plain; charset="iso-8859-1"

> This issue was reported to OpenSSL on 23rd September 2016 by Robert Święcki

Found by whom? Welcome to the 21st century...  :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate torture test

[David Woodhouse]

On Fri, 2016-09-02 at 20:20 +, Salz, Rich wrote:
> > I've started collecting a certificate torture test suite at
> > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/
> > Makefile.am
> 
> I think this is cool, and splitting it off is a good idea.  I think
> some IETF folks would be interested, too.

We've turned this into a nascent Internet-Draft. It's not filed yet;
preliminary feedback would be very welcome.

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

Pull requests accepted at
https://github.com/dwmw2/ietf-cert-best-practice

There's plenty of things I'm not quite sure about. In particular, is
there any reason why we'd want to use the new PKCS#8 formats defined in
RFC5958? OpenSSL doesn't support those at all, right? Does anyone?

Also, should we make any attempt to handle keys managed by a TPM? Or
can we rely on PKCS#11 for that?

I note that historically, the OpenSSL TPM ENGINE supported a 'TSS KEY
BLOB' PEM format which contained a TPM-wrapped key, and OpenConnect at
least would Just Work™ when handed such a PEM file.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] SSL_CTX_add_cient_custom_ext() and known extensions

[David Woodhouse]

The documentation for SSL_CTX_add_client_custom_ext() states that "the
extension type must not be handled by OpenSSL internally or an error
occurs".

This isn't entirely true. In custom_ext_meth_add() we have this
comment:

    /*
 * Don't add if extension supported internally, but make exception
 * for extension types that previously were not supported, but now are.
 */

The code that follows this comment just has an explicit exception for
TLSEXT_TYPE_signed_certificate_timestamp, so an application is allowed
to register its own handler for that even when OpenSSL does support it.

(With another hard-coded check in SSL_CTX_add_client_custom_ext() so
that you can only do so if you either don't *enable* OpenSSL's own SCT
support or do so *after* registering your custom handler. The
latter probably isn't intentional.)

I'm interested in what interpretation exists of "extension types that
previously were not supported, but now are" that isn't a tautology.

But mostly I'd like to know how it would relate to the PSK identity
support in draft-jay-tls-psk-identity-extension¹.

I'd like to use that extension for OpenConnect VPN, but I'm concerned
that when the RFC is published and OpenSSL starts to support it, my
call to SSL_CTX_add_client_custom_ext() would suddenly start failing.

Would it?


-- 
dwmw2

¹ https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-01

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate torture test

[David Woodhouse]

On Thu, 2016-09-08 at 13:44 +, Salz, Rich wrote:
> I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/c
> harter/), which is the closest thing to PKIX these days, and perhaps
> cross-post to the SAAG mailing list the general catch-all for
> security area https://trac.tools.ietf.org/area/sec/trac/wiki.

I sent this to both lists; thanks again.

It doesn't seem to have made it to either list yet, but hopefully it
will shortly.

-- 
dwmw2--- Begin Message ---
(I hope the cross-post is acceptable; apologies if not.)

Various applications will optionally make use of X.509 certificates for
client authentication.

Those certificates, and the associated private keys, may be found in
files on the file system, in PKCS#11 tokens, or in another
OS-specific form of certificate database.

In my opinion, it would be nice to have some consistency between
applications. If a user has a certificate in a certain form, it would
be nice for that to Just Work™ across all well-behaved applications.

In practice, nothing could be further from the truth.

Applications *all* suck, and various certificates will spuriously fail
to work in one application but not another. Or work if the application
is build against crypto library $A but not when built against crypto
library $B. Or for objects in PKCS#11 each application might require a
*different* identifier string to locate the same object. If they
support PKCS#11 at all.

I'd like to fix that. I would like to achieve a consensus that a "well-
behaved application" SHOULD accept certificates and keys in various
(TBD) file formats and also accept PKCS#11 URIs according to RFC7512.

I have slowly been working on this. I have encouraged the Fedora
distribution of Linux to amend their packaging guidelines to state that
software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it
would accept a filename. And that software SHOULD load the PKCS#11
tokens which are indicated by the system configuration.

We have already fixed various applications to comply with these
requirements, and I even mentored a Google Summer of Code project which
added RFC7512 support to NSS².

I believe the Fedora packaging guidelines have been a success, and I
would like to expand the scope. There's no *reason* this should be
Fedora-specific, or even specific to Linux or POSIX operating systems.
So I'm looking for a forum in which to reach a consensus on what should
be accepted, and to publish those guidelines. I'd be very interested in
hearing suggestions.


Simultaneously, I'm also looking at expanding the technical scope.
For my own project, the OpenConnect VPN client, I have started to
collect a torture test suite³ of RSA, DSA and EC keys in various
PKCS#1, PKCS#8 and PKCS#12 forms — both unencrypted, and encrypted with
various algorithms. I have yet to embark of the joy of files with non-
ASCII passphrases, especially in non-UTF8 locales — but I have a bottle
of vodka ready to help me do so.

My test suite also includes PKCS#11 tests including private keys where
the token doesn't expose the public component (which made OpenSSL crash
until yesterday, yay!) and certificates with the CKA_PRIVATE attribute
set, so some software will fail to *find* them.

I am thinking of splitting my torture test out from OpenConnect itself,
and making it available as a project in its own right.

I can, of course, lobby to expand the Fedora guidelines to state that
all software packaged for Fedora SHOULD pass the torture test suite,
but I think it makes sense to aim for a wider consensus than that.

Opinions welcome... does it make sense to attempt to publish an
informational RFC outlining such "expectations"? Or should it take some
other form? Or should I just not bother, and continue to push it from
the Fedora angle, since it's getting into a lot of upstream software
already?

I also expect some heckling at my specific test cases — do we *really*
expect everyone to support DSA keys still? And PEM files encrypted the
old OpenSSL way? And PKCS#12 files encrypted with MD5-DES?

(I can accept 'no' answers to the latter two only if expressed in a
form which lets me file bugs against ancient "enterprise" software to
stop *creating* them that way...)


-- 
dwmw2

¹ https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling
² https://bugzil.la/1162897
³ 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate torture test

[David Woodhouse]

On Thu, 2016-09-08 at 13:44 +, Salz, Rich wrote:
> I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/c
> harter/), which is the closest thing to PKIX these days, and perhaps
> cross-post to the SAAG mailing list the general catch-all for
> security area https://trac.tools.ietf.org/area/sec/trac/wiki.

Thanks.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate torture test

[David Woodhouse]

st Work.

I'm sure I can make a case for expanding that to cover a more
comprehensive set of file and PKCS#11 tests. And that *does* have a
knock-on effect in the wider ecosystem, as we fix upstream projects to
comply.

But this kind of thing shouldn't be distribution-specific. That just
*happens* to the policy handle that I can easily influence.

I haven't *yet* had an upstream push back and say that they don't want
to do this "just for Fedora", but it wouldn't surprise me to see it
happen.

I'd *really* like to achieve a wider consensus, and I'd very much
welcome suggestions for where and how to do that.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Certificate torture test

[David Woodhouse]

On Fri, 2016-09-02 at 20:20 +, Salz, Rich wrote:
> > I've started collecting a certificate torture test suite at
> > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
> 
> I think this is cool, and splitting it off is a good idea.  I think
> some IETF folks would be interested, too.

I'm tempted to split off the code with it. There's no way that
applications should have to have *hundreds* of lines of their own code
just to persuade the crypto library to use a cert/key pair specified by
the user.

Basically everything between
http://git.infradead.org/users/dwmw2/openconnect.git/blob/e048030f8:/openssl.c#l278
and
http://git.infradead.org/users/dwmw2/openconnect.git/blob/e048030f8:/openssl.c#l1012

... and the *whole* of openssl-pkcs11.c, is code I just don't want to
have in the *application*. I could just BSD-license it and put it out
there for people to use in the short term. In the (slightly) longer
term, of course, OpenSSL should do it all. Including PKCS#11.

FWIW, the torture test is now causing OpenSSL to crash because it
assumes all EC *private* keys will also have the public key available,
which isn't necessarily true when the key is in a hardware engine.
  https://github.com/openssl/openssl/issues/1532

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Certificate torture test

[David Woodhouse]

I've started collecting a certificate torture test suite at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

It has RSA, DSA and EC keys in various forms (PKCS#1, PKCS#8, PKCS#12
with varying encryptions), and PKCS#11.

I'm vaguely thinking about separating it from OpenConnect and making it
available as a generic test suite — and then perhaps trying to set
expectations that any application that can use SSL client certs/keys
should pass it.

Currently, every application you encounter on a Linux system will
support a *different* subset of the keys here. It would be nice to have
a bit of consistency.

Does that seem reasonable? Is there anything I'm missing from the tests
above? I know I need to add some non-ASCII password tests, and I need a
PKCS#11 test case where the certificate isn't visible until you log in
to the token. What else? Should I add PKCS#12 in PEM form for
completeness?

FWIW I hate all crypto libraries... there isn't *one* which simply has
a function that'll do the right thing and load a certificate given a
string which identifies it (by filename or PKCS#11 URI). GnuTLS comes
closest, I think, but we still have to jump through hoops in the
*application* to work out what kind of file we're looking at and ask
for it to be loaded. The library *really* ought to make that simple.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Tue, 2016-08-30 at 12:38 +0200, Andy Polyakov wrote:
> > So for other applications to try to read OpenSSL's PKCs#12 files, what
> > we need to do is first convert the sane Unicode rendition of the
> > password into the native locale charset (e.g. Windows-1252), then take
> > that bytestream and *pretend* it's ISO8859-1, and convert to UTF-16BE
> > to check the MAC. Then if that fails, take the same Windows-1252
> > bytestream and *pretend* it's UTF-8, and convert *that* to UTF-16BE to
> > see if it works.
> 
> Are you sure you want to know? I mean you already said "I wish I hadn't
> ask", and now you are bringing Windows into conversation :-) :-) :-)

I concede, I am a masochist. :)

> Yes, it's as bad as you can possibly imagine, and trouble is that there
> is no "right thing" to do *if* you formulate "keep old data accessible"
> as goal.

Yeah, if you want to be able to create PKCS#12 files that'll work (in
the same locale) with older versions of OpenSSL, you're kind of stuck.

I can live with that historical accident, and the workaround of
"convert to the locale charset, then pretend that's ISO8859-1 and try
again". I can even live with the fact that, for the reasons you've
stated, OpenSSL *still* produces files which need that workaround.

But I *really* wish you hadn't added *another* bug, and required
another workaround

> At the same time a way to access and generate
> specification-compliant data is provided (on *ix it takes *an* UTF8
> locale, which is default in absolute majority of cases bu now, and on
> Windows it's an *opt-in* environment variable for the time being).

... so instead of doing the UTF-8 thing whenever the incoming
bytestream happens to be interpretable as valid UTF-8, why not do it
only if LC_CTYPE actually *is* UTF-8?

So my (admittedly contrived and unlikely) example of "ĂŻ" in an
ISO8859-2 locale would only continue to do the *old* wrong thing, and
not a *new* wrong thing that needs an additional workaround :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 23:01 +0200, Andy Polyakov wrote:
> > 
> > So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
> > and the locale (not that it *should* matter) is ISO8859-2.
> When it comes to locale in *this* case you should rather wonder what
> does your terminal emulator program do and how does it interact with
> your shell. Because these two are responsible for composing the string
> that OPENSSL_[asc|utf8]2uni gets.

Right. And for the purpose of my example I have moved to eastern Europe
and fallen through a time-warp into the 20th century, so I'm using an
ISO8859-2 locale.

> > The correct rendition is 01 02 01 7b.
> Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as
> argument or console input under an UTF-8 locale. Otherwise it would have
> been passed as 'c3 af'.

No. My locale is ISO8859-2 so the password "ĂŻ" *is* passed as 'c3 af'.

Old OpenSSL will ignore the fact that the locale is ISO8859-2, and
perform an ISO8859-1 to UCS16BE conversion using the doubly-misnamed
OPENSSL_asc2uni() function. So it'll use '00 c3 00 af'.

New OpenSSL will ignore the fact that the locale is ISO8859-2, and
perform a UTF-8 to UCS16BE conversion using the only singly renamed
OPENSSL_utf82uni() function. So it'll use '00 ef'.

You had a bug because you made assumptions about the input data and
didn't properly convert from the locale charset to UTF16BE as you
should have done. Instead of fixing the bug, you just changed the
assumption you made to one that's slightly more likely to be valid in
today's world.

Leaving the rest of us with *two* buggy behaviours to try to work
around.

> > 
> > The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
> > to *convert* to ISO8859-2 (giving c3 af).
> No, no conversion from UTF-8 to ISO8859-x or any other conversion was
> *ever* performed. Nor is it performed now. It was and still is all about
> how string is composed by *somebody else*. That's why I said that "we
> assume that you don't change locale when you upgrade OpenSSL".

I'm talking about how other libraries should attempt to read the
PKCS#12 files created by OpenSSL. In my code I have the string "ĂŻ"
which the user has provided as the password. It doesn't matter what
charset it's in, as long as I *know* what charset it's in, and haven't
wantonly thrown that information away and started making *assumptions*
about how to interpret the stream of bytes.

So in order to try to emulate the old OpenSSL bug and read the file, I
need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and
treat it as ISO8859-1 for the purpose of converting to UTF16BE and
trying to decrypt. Which gives me the '00 c3 00 af' as above.

And in order to emulate the new OpenSSL bug and read the file, I need
to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it
as UTF-8 for the purpose of converting to UTF16BE and trying to
decrypt. Which gives me the '00 ef' that current OpenSSL will use.

This latter buggy behaviour hasn't actually been released yet, has it?
Is it too late to fix it properly?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 18:40 +0100, David Woodhouse wrote:
> 
> So... let's have a password 'nałve', in a ISO8859-2 environment where
> that is represented by the bytes 6e 61 b3 76 65.
> 
> First I should try the correct version according to the spec:
>  006e 0061 0142 0076 0065
> 
> Then we try the "OpenSSL assumed it was ISO8859-1" version:
>  006e 0061 00b3 0076 0065
> 
> And finally we try the "OpenSSL assumed it was UTF-8" version:
>  006e 0061 ... actually you *can't* convert that byte sequence "from"
> UTF-8 since it isn't valid UTF-8. So what will new OpenSSL do here,
> again?

In this specific example (the byte stream is not valid UTF-8 it looks
like OPENSSL_utf8touni() will assume it's actually ISO8859-1 and thus
the final case will be identical to the previous one.

So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
and the locale (not that it *should* matter) is ISO8859-2.

The correct rendition is 01 02 01 7b.

The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
to *convert* to ISO8859-2 (giving c3 af). Then to interpret those bytes
as ISO8859-1 (in which they would mean "ï") and convert *that* to
UTF16LE to give 00 c3 00 af

The "new buggy OpenSSL" rendition, again in the ISO8859-2 locale, would
again be to convert to ISO8859-2 (c3 af). Then to interpret those bytes
as UTF-8 (in which they would mean "ï") and convert *that* to UTF16LE
to give 00 ef.

Right?

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 15:25 +0200, Andy Polyakov wrote:
> First of all. *Everything* that is said below (and what modifications in
> question are about) applies to non-ASCII passwords. ASCII-only passwords
> are not affected by this and keep working as they were.
> 
> > 
> > > 
> > > commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9
> > > 
> > > OpenSSL versions before 1.1.0 didn't convert non-ASCII
> > > UTF8 PKCS#12 passwords to Unicode correctly.
> > > 
> > > To correctly decrypt older files, if MAC verification fails
> > > with the supplied password attempt to use the broken format
> > > which is compatible with earlier versions of OpenSSL.
> > > 
> > > Reviewed-by: Richard Levitte 
> > 
> > Hm, this sounds like something that other crypto libraries also ought
> > to try to work around. 
> > 
> > Please could you elaborate on the specific problem, and/or show a test
> > case?
> 
> Note that there is 80-test_pkcs12.t that refers to shibboleth.pfx.

Thanks.

> > I'm not quite sure how to interpret the patch itself. You pass the
> > password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() — which
> > is essentially converting ISO8859-1 to UTF-8.
> 
> You make it sound like these two are called one after another. But
> that's not what happens. It *tries* to access data with passwords
> converted with OPENSSL_asc2uni *or* OPENSSL_utf82uni, effectively
> independently of each other, in order to see which one is right. So that
> you can *transparently* access old broken data, as well as
> specification-compliant one.

Hm... at line 541 of pkcs12.c we call PKCS12_verify_mac(…mpass…) with
the original provided password. Which is in the locale-native character
set, is it not? No attempt to convert to anything known.

Then if that *fails* we do indeed convert it via OPENSSL_asc2uni() and
OPENSSL_uni2utf8() to make 'badpass' and try again:

} else if (!PKCS12_verify_mac(p12, mpass, -1)) {
/*
 * May be UTF8 from previous version of OpenSSL:
 * convert to a UTF8 form which will translate
 * to the same Unicode password.
 */
unsigned char *utmp;
int utmplen;
utmp = OPENSSL_asc2uni(mpass, -1, NULL, );
if (utmp == NULL)
goto end;
badpass = OPENSSL_uni2utf8(utmp, utmplen);
OPENSSL_free(utmp);
if (!PKCS12_verify_mac(p12, badpass, -1)) {
BIO_printf(bio_err, "Mac verify error: invalid password?\n");
ERR_print_errors(bio_err);
goto end;
} else {
BIO_printf(bio_err, "Warning: using broken algorithm\n");
if (!twopass)
cpass = badpass;
}

The shibboleth.pfx test seems to pass on the *first* call to
PKCS12_verify_mac() — it *isn't* testing this fallback. If I add a
space to the end of the correct password and stick a breakpoint on
PKCS12_verify_mac(), I see the following calls:

#0  PKCS12_verify_mac (p12=0x956e40, 
pass=0x956a30 "σύνθημα γνώρισμα ", passlen=-1)
at crypto/pkcs12/p12_mutl.c:152
#1  0x00425567 in pkcs12_main (argc=0, argv=0x7fffdd90)
at apps/pkcs12.c:541


And then it converts that string from ISO8859-1 (which it wasn't) to
UTF-8, and calls PKCS12_verify_mac() again:

#0  PKCS12_verify_mac (p12=0x956e40, 
pass=0x9597e0 "Ï\302\203Ï\302\215νθημα
γνÏ\302\216Ï\302\201ιÏ\302\203μα ", passlen=-1) at
crypto/pkcs12/p12_mutl.c:152
#1  0x004255fc in pkcs12_main (argc=0, argv=0x7fffdd90)
at apps/pkcs12.c:554

> > 
> > So, if my password is "naïve". In UTF-8 that's 6e 61 c3 af 76 65, which
> > is the correct sequence of bytes to use for the password?
> 
> 00 6e 00 61 00 ef 00 76 00 65, big-endian UTF-16.

Is that conversion done inside PKCS12_verify_mac()? Because we
definitely aren't passing UTF-16-BE into PKCS12_verify_mac().

> > 
> > And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65
> > by assuming it's ISO8859-1 (which would be 'naïve') and converting to 
> > UTF-8?
> 
> I don't follow. Why would it have to be converted to this sequence?

That's what it's doing. Changing the example above and showing the same
breakpoints as they get hit again...

Starting program: /home/dwmw2/git/openssl/apps/openssl pkcs12 -noout -password 
pass:naïve -in test/shibboleth.pfx
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PKCS12_verify_mac (p12=0x956e30, pass=0x956a30 "naïve", 
passlen=-1) at crypto/pkcs12/p12_mutl.c:152
152 if (p12->mac == NULL) {
(gdb) x/7bx pass
0x956a30:   0x6e0x610xc30xaf0x760x650x00
(gdb) c
Continuing.

Breakpoint 1, PKCS12_verify_mac (p12=0x956e30, pass=0x959960 "naïve", 
passlen=-1) at crypto/pkcs12/p12_mutl.c:152
152 if (p12->mac == NULL) {
(gdb) x/8bx pass
0x959960:   0x6e0x610xc30x83 

Re: [openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Wed, 2016-08-24 at 18:55 +0100, Dr. Stephen Henson wrote:
> commit 647ac8d3d7143e3721d55e1f57730b6f26e72fc9
>
> OpenSSL versions before 1.1.0 didn't convert non-ASCII
> UTF8 PKCS#12 passwords to Unicode correctly.
> 
> To correctly decrypt older files, if MAC verification fails
> with the supplied password attempt to use the broken format
> which is compatible with earlier versions of OpenSSL.
> 
> Reviewed-by: Richard Levitte 

Hm, this sounds like something that other crypto libraries also ought
to try to work around. 

Please could you elaborate on the specific problem, and/or show a test
case?

I'm not quite sure how to interpret the patch itself. You pass the
password through OPENSSL_asc2uni() and then OPENSSL_uni2utf8() — which
is essentially converting ISO8859-1 to UTF-8.

So, if my password is "naïve". In UTF-8 that's 6e 61 c3 af 76 65, which
is the correct sequence of bytes to use for the password?

And you now convert that sequence of bytes to 6e 61 c3 83 c2 af 76 65
by assuming it's ISO8859-1 (which would be 'naïve') and converting to
UTF-8?

So... what was the bug that was actually being worked around? That
older versions were converting from the local charset to UTF-8 twice in
a row? So you've implemented a "convert ISO8859-1 to UTF-8" fallback
which will cope with that in *some* locales but not all...? I don't
really understand.

Thanks for any light you can shed on it!

/me goes off to add non-ASCII passwords to the growing torture test
suite at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] crypto/ui/ui_openssl.c: let new-line through after query in Windows path.

[David Woodhouse]

On Mon, 2016-08-01 at 10:48 +0200, Andy Polyakov wrote:
> Originally new-line was suppressed, because double new-line was
> observed under wine. But it appears rather to be a wine bug,
> because on real Windows new-line is much needed.
> 
> Reviewed-by: Richard Levitte <levi...@openssl.org>

Hm, this commit comment needs an explicit reference to the mentioned
bug in bugs.winehq.org.

I can't find it. Is it related to 
https://bugs.winehq.org/show_bug.cgi?id=27229 ?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain

[David Woodhouse]

On Tue, 2016-08-09 at 02:08 +, Viktor Dukhovni wrote:
> On Tue, Aug 09, 2016 at 01:45:24AM +, William M Edmonds via RT wrote:
> 
> > 
> > If I specify a CAfile that includes the leaf certificate and/or
> > intermediate CA certificates, but not the root certificate, then
> > verification fails.
> 
> As expected, unless you use the "-partial" flag in the command-line
> utilities, or use the X509_VERIFY_PARAM_set_flags() to set the
> X509_V_FLAG_PARTIAL_CHAIN flag when using the API.

Is there an equivalent for 1.0.1?

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Session resume with different TLS version?

[David Woodhouse]

On Tue, 2016-07-26 at 23:52 +, David Benjamin wrote:
> Ah, you've hit upon a slew of odd behaviors which only got fully fixed on the 
> master branch.

Thanks for the comprehensive response. I'm not going to touch that with
a barge-pole then.

> (I'm not familiar with DTLS1_BAD_VER, but if it's a different
> protocol version, it sounds like you should configure it like other
> versions and not mess with session resumption bugs.)

It's a different protocol version, and the *only* way it ever gets used
in the modern world is with a session resume (because that's how
Cisco's AnyConnect VPN works). Hence the thought process was that if
the session resume would *force* the protocol version (which you now
told me it shouldn't, for the client), then I wouldn't *need* any other
method of specifying it.

In RT#3711 we had previously talked about the option of enabling full
support via something like DTLSv0_9_client_method(), and it had been
decided not to — on the basis that the existing SSL_OP_CISCO_ANYCONNECT
hack was sufficient.

That's less true now with the generic DTLS_client_method() and
DTLS_ANY_VERSION, because the SSL_OP_CISCO_ANYCONNECT hack needs to be
propagated into a lot more places and it actually ends up being
*cleaner* to implement it "properly" AFAICT.

I've updated my submission in PR#1296 accordingly; thanks for the
feedback.

https://github.com/openssl/openssl/pull/1296

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Session resume with different TLS version?

[David Woodhouse]

The deprecation of the version-specific methods such as
DTLSv1_client_method() has introduced a regression — the
SSL_OP_CISCO_ANYCONNECT hack doesn't work with DTLS_client_method().

I'm looking into fixing that (in PR#1296 along with a test case and
some fixes for various other regressions). In doing so, I uncovered a
slightly more generic question...

If I am resuming a session with SSL_set_session(), and that previous
session used a specific protocol... should we negotiate that *same*
protocol again, effectively setting the minimum and maximum protocol
versions to s->session->ssl_version?

Given that DTLS1_BAD_VER only *ever* needs to be used in a session
resume, that would be a perfectly acceptable way to obtain it...

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4631] Another DTLS1_BAD_VER regression in 1.0.2

[David Woodhouse via RT]

This fix and and some other regression fixes, along with a test case,
are lined up for HEAD/1.1 in Github PR #1296.

This one is also needed in 1.0.2.


-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4631
Please log in as guest with password guest if prompted

>From 6f4560482c6a942c57842518f80b92ef97167e75 Mon Sep 17 00:00:00 2001
From: David Woodhouse <david.woodho...@intel.com>
Date: Fri, 8 Jul 2016 20:46:07 +0100
Subject: [PATCH] Fix SSL_export_keying_material() for DTLS1_BAD_VER

Commit d8e8590e ("Fix missing return value checks in SCTP") made the
DTLS handshake fail, even for non-SCTP connections, if
SSL_export_keying_material() fails. Which it does, for DTLS1_BAD_VER.

Apply the trivial fix to make it succeed, since there's no real reason
why it shouldn't even though we never need it.
---
 ssl/ssl_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index a707612..42b980a 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -1828,7 +1828,7 @@ int SSL_export_keying_material(SSL *s, unsigned char *out, size_t olen,
const unsigned char *p, size_t plen,
int use_context)
 {
-if (s->version < TLS1_VERSION)
+if (s->version < TLS1_VERSION && s->version != DTLS1_BAD_VER)
 return -1;
 
 return s->method->ssl3_enc->export_keying_material(s, out, olen, label,
-- 
2.7.4



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Mon, 2016-07-25 at 16:29 +0100, David Woodhouse wrote:
> I'm currently trying to stop it whining about DTLSv1_client_method()
> being deprecated; I can't see how to make it work using
> DTLS_client_method().

The SSL_OP_CISCO_ANYCONNECT hack doesn't work so well with
DTLS_client_method. Instead of there being one simple place where we
can set s->client_version = s->version = DTLS1_BAD_VER, we'd end up
having to play silly buggers in quite a few places. So I figured I
should probably just do it properly with support for DTLS1_BAD_VER, as
below.

Although arguably, if I've used SSL_set_session() such that
s->session->ssl_version == DTLS1_BAD_VER, that should have been
honoured.

Two new commits at the tip of PR#1296 for comment...
https://github.com/openssl/openssl/pull/1296/commits/a1c341f7
(Make DTLS1_BAD_VER work with DTLS_client_method())

https://github.com/openssl/openssl/pull/1296/commits/41800497
(Honour SSL version in SSL_set_session()).

Not entirely sure if those are the best approach... but hey, you have a
test case now :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote:
> 
> We have no test suite coverage doing anything with DTLS1_BAD_VER
> and I think the OpenConnect VPN is the only user of it.

I added a basic test in PR #1296. It just simulates the basic session
resume and — since it seemed relatively trivial to add while I was at
it — out-of-order packet RX:
https://github.com/openssl/openssl/pull/1296/commits/9538be65

This test catches all the bugs that the pull request fixes, and also
tests the session resume method that OpenConnect uses, of manually
building the ASN.1 with the session details and then using
d2i_SSL_SESSION().

It validates the handshake MAC, which is different for DTLS1_BAD_VER
because it doesn't include the handshake message headers.

It also checks the handling of the 3-byte Change Cipher Spec message,
in both directions.

I'm currently trying to stop it whining about DTLSv1_client_method()
being deprecated; I can't see how to make it work using
DTLS_client_method().

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[David Woodhouse via RT]

(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire — because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[David Woodhouse]

(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire — because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[David Woodhouse via RT]

On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote:
> 
> 
> Looking at the various places in the code where get_issuer
> and check_issued are accessed, they mostly use the context rather than
> the store. Here are the places I have found:
> 
> https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71
> 
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581
> 
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059
> 
> https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997
> 
> And the following one actually uses the store and not the context:
> 
> https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire — because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if we
can have an accessor I'd much rather go back to doing it the old way.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)


-- 
dwmw2


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[David Woodhouse]

On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote:
> 
> 
> Looking at the various places in the code where get_issuer
> and check_issued are accessed, they mostly use the context rather than
> the store. Here are the places I have found:
> 
> https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71
> 
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581
> 
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059
> 
> https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997
> 
> And the following one actually uses the store and not the context:
> 
> https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire — because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if we
can have an accessor I'd much rather go back to doing it the old way.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)


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

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 23:59 +0200, Kurt Roeckx wrote:
> 
> Can you describe how DTLS1_BAD_VER is supposed to work?  Is this
> version send over the wire?  Is it negotiated?

It does indeed appear on the wire.

In the AnyConnect/OpenConnect case — which, as you rightly observe, is
the only remaining user of this version of the protocol — it's not
actually negotiated in the normal sense at all; we "resume" a session
having established the master secret and session-id over a separate
channel.

http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/dtls.c#l157

> We have no test suite coverage doing anything with DTLS1_BAD_VER
> and I think the OpenConnect VPN is the only user of it.

Yeah, test coverage would be useful... I'm not sure how complete our
*server* side support of DTLS1_BAD_VER is. I did start looking at it
briefly once, but got distracted. I'll have another look.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 19:13 +, Viktor Dukhovni wrote:
> 
> Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests
> that you're actually doing a comparison. 

Well, 'cmp' with one argument isn't *so* easily interpreted as a
comparison, but OK :)

I've also added a comment explaining a little about what's going on.


>  Given this macro, one
> might consider complementing the versions, so that the ordinals
> compare in the usual way:
> 
>     #define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0x ^ 
> (v)))

I suppose we can, if someone feels strongly about it. It didn't seem
worth the additional churn.

One of 4 patches in https://github.com/openssl/openssl/pull/1296 which
actually make OpenConnect work again...

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Fix missing return value checks in SCTP

[David Woodhouse]

On Tue, 2015-08-11 at 19:36 +0100, Matt Caswell wrote:
> There are some missing return value checks in the SCTP code. In master this
> was causing a compilation failure when config'd with
> "--strict-warnings sctp".
> 
> Reviewed-by: Tim Hudson <t...@openssl.org>
> ---
>  ssl/d1_clnt.c | 16 
>  ssl/d1_srvr.c | 18 +-
>  2 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/ssl/d1_clnt.c b/ssl/d1_clnt.c
> index 566c154..d411614 100644
> --- a/ssl/d1_clnt.c
> +++ b/ssl/d1_clnt.c
> @@ -364,11 +364,15 @@ int dtls1_connect(SSL *s)
>   sizeof(DTLS1_SCTP_AUTH_LABEL),
>   DTLS1_SCTP_AUTH_LABEL);
>  
> -SSL_export_keying_material(s, sctpauthkey,
> +if (SSL_export_keying_material(s, sctpauthkey,
> sizeof(sctpauthkey),
> labelbuffer,
> sizeof(labelbuffer), NULL, 0,
> -   0);
> +   0) <= 0) {
> +ret = -1;
> +s->state = SSL_ST_ERR;
> +goto end;
> +}
>  
>  BIO_ctrl(SSL_get_wbio(s),
>   BIO_CTRL_DGRAM_SCTP_ADD_AUTH_KEY,

This commit (d8e8590e) and its backport to 1.0.2 (b3a62dc0) have broken
OpenConnect when SCTP is enabled, because SSL_export_keying_material()
*does* fail there. Perhaps it shouldn't...

diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 08e3673..6db4f3a 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -2231,7 +2231,7 @@ int SSL_export_keying_material(SSL *s, unsigned char 
*out, size_t olen,
const unsigned char *p, size_t plen,
int use_context)
 {
-if (s->version < TLS1_VERSION)
+if (s->version < TLS1_VERSION && s->version != DTLS1_BAD_VER)
 return -1;
 
 return s->method->ssl3_enc->export_keying_material(s, out, olen, label,

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Fri, 2016-07-08 at 17:43 +0100, David Woodhouse wrote:
> On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> > Reviewed-by: Viktor Dukhovni <vik...@openssl.org>
> > 
> > MR: #1595
> > ---
> >  ssl/s3_lib.c | 534 
> > +++
> >  ssl/ssl_ciph.c   | 196 +
> >  ssl/ssl_lib.c    |   4 +-
> >  ssl/ssl_locl.h   |  21 +-
> >  ssl/ssl_txt.c    |   2 +-
> >  ssl/statem/statem_clnt.c |  18 +-
> >  ssl/statem/statem_lib.c  |   6 +-
> >  ssl/t1_lib.c |  41 ++--
> >  8 files changed, 504 insertions(+), 318 deletions(-)
> > 
> > diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> > index 51fb161..093ff09 100644
> > --- a/ssl/s3_lib.c
> > +++ b/ssl/s3_lib.c
> > @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
> >   SSL_aRSA,
> >   SSL_eNULL,
> >   SSL_MD5,
> > - SSL_SSLV3,
> > + SSL3_VERSION, TLS1_2_VERSION,
> > + DTLS1_VERSION, DTLS1_2_VERSION,
> 
> This broke the OpenConnect VPN client, which now fails thus:
> 
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers 
> available:ssl/statem/statem_clnt.c:927:
> 
> I tried the naïvely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.

Of course, it's because DTLS_VERSION_LT and friends are doing precisely
the opposite of what their names imply, numerically. I hesitate to call
this a 'fix' but it highlights the issue:

diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
index ef5eb8c..218dcce 100644
--- a/ssl/ssl_locl.h
+++ b/ssl/ssl_locl.h
@@ -259,10 +259,11 @@
   c[1]=(unsigned char)(((l)>> 8)&0xff), \
   c[2]=(unsigned char)(((l))&0xff)),c+=3)
 
-#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
-#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
-#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
-#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
+#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
+#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
+#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
+#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
+#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))
 
 /* LOCAL STUFF */
 
> 
> Having said that, reverting this change isn't *sufficient* to fix
> OpenSSL 1.1; it still fails with 
> 
> DTLS handshake failed: 1
> 67609664:error:14160098:SSL routines:read_state_machine:excessive message 
> size:ssl/statem/statem.c:586:
> 
> ... which goes back to before 1.1.0-pre1. I'll find that one later...

That one's simpler:

diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index 26c4d10..b2160cd 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -704,6 +704,8 @@ unsigned long ossl_statem_client_max_message_size(SSL *s)
 return SERVER_HELLO_DONE_MAX_LENGTH;
 
 case TLS_ST_CR_CHANGE:
+if (s->client_version == DTLS1_BAD_VER)
+return 3;
 return CCS_MAX_LENGTH;
 
 case TLS_ST_CR_SESSION_TICKET:
-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[David Woodhouse]

On Sun, 2016-02-07 at 20:17 +0100, Kurt Roeckx wrote:
> Reviewed-by: Viktor Dukhovni 
> 
> MR: #1595
> ---
>  ssl/s3_lib.c | 534 
> +++
>  ssl/ssl_ciph.c   | 196 +
>  ssl/ssl_lib.c    |   4 +-
>  ssl/ssl_locl.h   |  21 +-
>  ssl/ssl_txt.c    |   2 +-
>  ssl/statem/statem_clnt.c |  18 +-
>  ssl/statem/statem_lib.c  |   6 +-
>  ssl/t1_lib.c |  41 ++--
>  8 files changed, 504 insertions(+), 318 deletions(-)
> 
> diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> index 51fb161..093ff09 100644
> --- a/ssl/s3_lib.c
> +++ b/ssl/s3_lib.c
> @@ -171,7 +171,8 @@ static const SSL_CIPHER ssl3_ciphers[] = {
>   SSL_aRSA,
>   SSL_eNULL,
>   SSL_MD5,
> - SSL_SSLV3,
> + SSL3_VERSION, TLS1_2_VERSION,
> + DTLS1_VERSION, DTLS1_2_VERSION,

This broke the OpenConnect VPN client, which now fails thus:

DTLS handshake failed: 1
67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers 
available:ssl/statem/statem_clnt.c:927:

I tried the naïvely obvious step of changing all instances of
DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.


Having said that, reverting this change isn't *sufficient* to fix
OpenSSL 1.1; it still fails with 

DTLS handshake failed: 1
67609664:error:14160098:SSL routines:read_state_machine:excessive message 
size:ssl/statem/statem.c:586:

... which goes back to before 1.1.0-pre1. I'll find that one later...

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4464] UEFI/EDK2 build broken by removal of 'make files'.

[David Woodhouse]

On Mon, 2016-03-21 at 11:55 +0100, Richard Levitte wrote:
> Something like this in the directory where you find configdata.pm:
> 
>     $ perl opensslinf.pl > OpensslLib.inf
> 
> opensslinf.pl:

 ...

That works; thank you. It appears to give me rand/rand_vms.c which I
didn't have before, that that's harmless. And it obviously gives me 
bio/b_print.c which I was manually filtering out before — I need to do 
something better than that!

It also means I need to try to remember some perl because my test is
currently just using your perl snippet and feeding it to the sed
command I had before... which is *stupid*. But that's my problem :)

function filelist ()
{
echo '1,/# Autogenerated files list starts here/p'
echo '/# Autogenerated files list ends here/,$p'
echo '/# Autogenerated files list starts here/a\'

perl <{\$product}}) {
foreach my \$s (@{\$unified_info{sources}->{\$o}}) {
next if \$unified_info{generate}->{\$s};
print "  \\\$(OPENSSL_PATH)/", \$s, "\r\n";
}
}
}
EOF
echo -e \\r
}

filelist  |  sed -n -f - -i OpensslLib.inf

> Note that it skips over generated source, something that LIBSRC never
> contained anyway...

Yeah, we don't use any generated source. The only generated file we use
is opensslconf.h, and we stash our own copy of that away as part of the
same script I'm looking at here.

Once EDK2 starts using NASM instead of having *different* copies of
various asm files for the MSVC vs. GCC builds(!!), perhaps I'll look at
whether I can stop using no-asm. But that's a game for another day.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4464] UEFI/EDK2 build broken by removal of 'make files'.

[David Woodhouse via RT]

The EDK2 build was using 'make files', as follows:


make files
cd -

function filelist ()
{
echo '1,/# Autogenerated files list starts here/p'
echo '/# Autogenerated files list ends here/,$p'
echo '/# Autogenerated files list starts here/a\'

while read LINE; do
case "$LINE" in
RELATIVE_DIRECTORY=*)
eval "$LINE"
;;
LIBSRC=*)
LIBSRC=$(echo "$LINE" | sed s/^LIBSRC=//)
for FILE in $LIBSRC; do
if [ "$FILE" != "b_print.c" ]; then
echo -e '  
$(OPENSSL_PATH)/'$RELATIVE_DIRECTORY/$FILE\\r\\
fi
done
;;
esac
done
echo -e \\r
}

filelist < "${OPENSSL_PATH}/MINFO" |  sed -n -f - -i OpensslLib.inf


It wasn't pretty, but it worked. Now it doesn't. What should I be doing
instead?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4464
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl cms unable to access keys on token?

[David Woodhouse]

On Mon, 2016-03-14 at 22:34 +, Blumenthal, Uri - 0553 - MITLL wrote:
> I’d personally prefer the cms app to have internal logic “if -engine is
> specified and the cert name starts with ‘pksc11:’ then load it via
> engine”.

So you don't want the -keyform argument to exist either? That would
also be redundant, by the same logic. And I'm not sure it's true.

> It’s been suggested in another forum that perhaps openssl should
> automatically load the appropriate engine if the resource (key || pubkey
> || cert) is specified via URI that starts with the engine name (like
> “pkcs11:”).

I dislike this, because it could be used to provoke OpenSSL into
loading arbitrary engines. It also dramatically increases the chance of
accidental collision with real filenames.

But I suppose if it was restricted to explicitly-configured prefixes,
that would be tolerable.

But seriously, I was mostly planning to ditch the engine completely for
PKCS#11, and add code to crypto/pkcs11/ to do things directly.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl cms unable to access keys on token?

[David Woodhouse]

On Mon, 2016-03-14 at 21:28 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> You are right - the command line was wrong. Here’s the correct line,
> which
> should work, but doesn’t:
> 
> $ openssl cms -engine pkcs11 -aes256 -encrypt -in data.txt -binary
> -outform PEM -out data.txt.enc
> "pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert"

Yeah, that won't work either. 

Perhaps you need the "-certform engine" option.

Which doesn't exist. :)

(My mailer doesn't seem to trust your signing cert, btw. Should you be
including an intermediate certificate in your messages? For that
matter, should I? :)


-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl cms unable to access keys on token?

[David Woodhouse]

On Mon, 2016-03-14 at 19:27 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> $ openssl cms -engine pkcs11 -aes256 -encrypt -binary -in data.txt
> -outform engine "pkcs11:object=KEY%20MAN%20pubkey;object-type=public"

That isn't what -outform does. It controls the output format of the
encrypted result:

$ openssl cms -aes256 -encrypt -binary -in data.txt -outform PEM cert.pem
-BEGIN CMS-
MIICIgYJKoZIhvcNAQcDoIICEzCCAg8CAQAxggHKMIIBxgIBADCBrTCBpzELMAkG
...

There is no option which makes it obtain the *certificate* (to which it
is encrypting the CMS message) from an engine. There isn't even a
standard way for an engine to provide such functionality — the PKCS#11
engine currently exposes it only with a custom "LOAD_CERT_CTRL"
command.

This is just one of many reasons why libp11/engine_pkcs11 needs to die
as a separate project, and we need to incorporate proper PKCS#11
support into OpenSSL natively.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4408] [PATCH] Remove last traces of CRYPTO_dynlock for non-compatibility build

[David Woodhouse via RT]

Commit 2e52e7df5 ("Remove the old threading API") left a dummy definition
of the CRYPTO_dynlock for compatibility, if OPENSSL_API_COMPAT < 1.1.0.

However, there's still a DEFINE_STACK_OF(CRYPTO_dynlock) in cryptlib.h
which isn't so masked, and breaks the build if you disable the API
compatibility. Assuming that's supposed to be present too for the same
reason, wrap it in a similar #ifdef.
---
 crypto/include/internal/cryptlib.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/include/internal/cryptlib.h 
b/crypto/include/internal/cryptlib.h
index a97e20b..18d205e 100644
--- a/crypto/include/internal/cryptlib.h
+++ b/crypto/include/internal/cryptlib.h
@@ -82,7 +82,9 @@ typedef struct ex_callback_st EX_CALLBACK;
 
 DEFINE_STACK_OF(EX_CALLBACK)
 
+# if OPENSSL_API_COMPAT < 0x1010L
 DEFINE_STACK_OF(CRYPTO_dynlock)
+# endif
 
 typedef struct app_mem_info_st APP_INFO;
 DEFINE_LHASH_OF(APP_INFO);
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4408
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Sat, 2016-02-20 at 12:40 -0800, Sander Temme wrote:
> However, I’m intrigued by the notion of a PKCS#11 Engine in OpenSSL:
> it’s a standard (an OASIS standard now); it’s fairly fully featured;
> everyone in the industry supports it including Thales; and you can
> build a program that calls it without needing a vendor SDK, because
> there are standard headers and a well defined way to get to the entry
> points.  If we can come up with a way to pick a PKCS#11 slot and log
> into it that makes sense (e.g. not by poking PINs into a system wide
> config file etc.) then I think we’d have a winner.

OK, let's explore that. Let's assume, purely for the sake of this
discussion, that we ditch the engine from OpenSSL 1.1 and go *purely*
with a solution based around the existing engine_pkcs11.

From your point of view, what problems are there with that scenario?

You talk about "a way to pick a PKCS#11 slot and log into it"... that's
basically handled by RFC7512, isn't it? The PKCS#11 URI gives us a
standard way to specify not only the slot but also the object therein.
It *also* allows a pin-value attribute to be encoded within the URI if
you want to do that.

If you don't want to encode the PIN, it can be requested at runtime via
a UI_METHOD that you provide. I see the Chil engine also supports an
alternative callback function... does that really provide any more
functionality than your own UI_METHOD does? We could potentially add
that... if we must.

Are there any (other) gaps in required functionality?

Note that engine_pkcs11 doesn't currently support the ?module-path=
query attribute. The code flow of the engine doesn't make that trivial,
since we initialise the engine (and load the provider module) first and
only *later* do we get given a URI to deal with. It's not beyond the
wit of man to fix that though, if we need to.

We *haven't* needed to care about it so far, though. General-purpose
builds (such as building packages for Linux distributions) tend to just
use p11-kit-proxy.so as the default module. That just makes us obey the
*system* configuration for which PKCS#11 modules should be visible to
which applications. And special-purpose use cases can specify a module
in advance when loading the engine. Anyone migrating code which
explicitly uses the Chil engine to engine_pkcs11 would be able to
specify the appropriate module path when loading the engine.

For sanely maintained Linux distributions at least, I want to get to a
point where *any* application which can take certs/keys from a file,
should *also* accept a PKCS#11 URI in place of a file name and should
just work. The Fedora packaging guidelines already say that this SHOULD
be the case, FWIW.

> What I would like to see though is for such a PKCS#11 Engine to be
> part of OpenSSL proper,

Yeah yeah, but not for 1.1. Some of us are hoping to fix that for 1.2
(and not necessarily as an ENGINE but more by having PKCS#11 support
properly integrated). We have agreement from copyright-holders of most
of the existing engine (and libp11, where most of the *functionality*
lies) to relicense it and include it in OpenSSL.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4347] Fix GCC unused-value warnings with HOST_c2l()

[David Woodhouse via RT]

a, b, c, d, e, f, g);
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 T1 = X[10] = l;
 ROUND_00_15(10, g, h, a, b, c, d, e, f);
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 T1 = X[11] = l;
 ROUND_00_15(11, f, g, h, a, b, c, d, e);
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 T1 = X[12] = l;
 ROUND_00_15(12, e, f, g, h, a, b, c, d);
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 T1 = X[13] = l;
 ROUND_00_15(13, d, e, f, g, h, a, b, c);
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 T1 = X[14] = l;
 ROUND_00_15(14, c, d, e, f, g, h, a, b);
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 T1 = X[15] = l;
 ROUND_00_15(15, b, c, d, e, f, g, h, a);
 }
diff --git a/crypto/sha/sha_locl.h b/crypto/sha/sha_locl.h
index 87e69d8..649cded 100644
--- a/crypto/sha/sha_locl.h
+++ b/crypto/sha/sha_locl.h
@@ -430,7 +430,7 @@ static void HASH_BLOCK_DATA_ORDER(SHA_CTX *c, const void 
*p, size_t num)
 
 for (;;) {
 for (i = 0; i < 16; i++) {
-HOST_c2l(data, l);
+(void)HOST_c2l(data, l);
 X[i] = l;
 BODY_00_15(X[i]);
 }
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4347
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4339] [PATCH] Fix handling of in UEFI build

[David Woodhouse via RT]

The entire contents of  are unwanted in the UEFI
build because we have to do it differently there. To support building
for both 32-bit and 64-bit platforms without re-running the OpenSSL
Configure script, the EDK2 environment defines THIRTY_TWO_BIT or
SIXTY_FOUR_BIT for itself according to the target platform.

The current setup is broken, though. It checks for OPENSSL_SYS_UEFI but
before it's actually defined, since opensslconf.h hasn't yet been
included.

Let's fix that by including opensslconf.h. And also let's move the
bn_conf.h doesn't even need to *exist* in the UEFI build environment.
---
 crypto/bn/bn_lcl.h   | 6 ++
 crypto/include/internal/bn_conf.h.in | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/crypto/bn/bn_lcl.h b/crypto/bn/bn_lcl.h
index 0f3205c..a0a857b 100644
--- a/crypto/bn/bn_lcl.h
+++ b/crypto/bn/bn_lcl.h
@@ -111,7 +111,13 @@
 #ifndef HEADER_BN_LCL_H
 # define HEADER_BN_LCL_H
 
+/* The EDK2 build sets these externally since it doesn't re-run our
+ * own Configure script and needs to support both 32-bit and 64-bit */
+#include 
+
+# if !defined(OPENSSL_SYS_UEFI)
 # include "internal/bn_conf.h"
+# endif
 # include "internal/bn_int.h"
 
 #ifdef  __cplusplus
diff --git a/crypto/include/internal/bn_conf.h.in 
b/crypto/include/internal/bn_conf.h.in
index 5ebd55d..ceb4cba 100644
--- a/crypto/include/internal/bn_conf.h.in
+++ b/crypto/include/internal/bn_conf.h.in
@@ -56,7 +56,9 @@
 #ifndef HEADER_BN_CONF_H
 # define HEADER_BN_CONF_H
 
-# if !defined(OPENSSL_SYS_UEFI)
+/* The contents of this file are not used in the UEFI build, as
+ * both 32-bit and 64-bit builds are supported from a single run
+ * of the Configure script. */
 
 /* Should we define BN_DIV2W here? */
 
@@ -64,6 +66,5 @@
 {- $config{b64l} ? "#define" : "#undef" -} SIXTY_FOUR_BIT_LONG
 {- $config{b64}  ? "#define" : "#undef" -} SIXTY_FOUR_BIT
 {- $config{b32}  ? "#define" : "#undef" -} THIRTY_TWO_BIT
-# endif
 
 #endif
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4339
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Mon, 2016-02-22 at 14:46 +, Salz, Rich wrote:
> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> > function which takes a filename for a cert or key should also accept¹ a
> > PKCS#11 URI.
> 
> It'd be great to see a crypto/pkcs11 directory with full native support (as 
> much as possible).
> 
> But really doubtful to happen in 1.1 as the API freeze is in a month.

Sure, it'd be insane to target 1.1 well, except that libp11 is
basically *designed* to be dropped into crypto/pkcs11 except for being
under the LGPL. And its original author has already agreed to relicense
it more sensibly.

But yeah — realistically speaking, we are talking about 1.2 (or
whatever comes next). We have libp11+engine_pkcs11 for now.

I absolutely don't want to waste the effort though, so seeing you say
things like "it'd be great to have" is actually really useful.

So let me outline the plan a little bit and see if you still think it's
a good idea...

I was intending to use libp11-kit for the basic PKCS#11 module
enumeration and handling. On the *nix platforms where PKCS#11 is most
important, p11-kit is fairly much ubiquitous. Obviously the code would
be designed such that if someone really wants to eliminate that
requirement, they could reimplement all the things that libp11-kit
gives us and make it a build-time option. But seriously, why would you?

I'd start by throwing together the code to implement the various
EVP_PKEY types work based on PKCS#11 calls, and then look at Richard's
STORE code and how we'd want to tie that in with the use of PKCS#11
URIs to identify objects.

If other libp11 contributors are happy to relicense, that means I can
lift big chunks of code from there. Otherwise I get to reinvent the
wheel.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4334] Check for UEFI before __STDC_VERSION__ for

[David Woodhouse via RT]

Adding -nostdinc to the EDK2 showed that we were including 
for some UEFI builds, because the check for __STDC_VERSION__ happens
before the check for OPENSSL_SYS_UEFI. Fix that.
---
 include/openssl/e_os2.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index b66b1cc..ba3345a 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -286,11 +286,7 @@ extern "C" {
 # endif
 
 /* Standard integer types */
-# if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
- defined(__osf__) || defined(__sgi) || defined(__hpux) || \
- defined(OPENSSL_SYS_VMS)
-#  include 
-# elif defined(OPENSSL_SYS_UEFI)
+# if defined(OPENSSL_SYS_UEFI)
 typedef INT8 int8_t;
 typedef UINT8 uint8_t;
 typedef INT16 int16_t;
@@ -299,7 +295,11 @@ typedef INT32 int32_t;
 typedef UINT32 uint32_t;
 typedef INT64 int64_t;
 typedef UINT64 uint64_t;
-#define PRIu64 "%Lu"
+#  define PRIu64 "%Lu"
+# elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
+ defined(__osf__) || defined(__sgi) || defined(__hpux) || \
+ defined(OPENSSL_SYS_VMS)
+#  include 
 # elif defined(_MSC_VER) && _MSC_VER<=1500
 /*
  * minimally required typdefs for systems not supporting inttypes.h or
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4334
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Mon, 2016-02-22 at 12:52 +0100, Richard Levitte wrote:
> 
> That takes me back to crypto/store, which is currently removed in
> master but which I have a rework of in a branch, which is meant to
> solve this exact problem, but without being exclusively tied to
> PKCS#11.  The design is to have it work with engine backends, and a
> PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

That seems ideal. The TPM ENGINE could benefit from it too.

I'd really like to look at this from the *application* developer's
point of view.

Please clear your mind of any internal OpenSSL knowledge and context,
and take a look at the OpenConnect VPN client, and the various hoops it
has to jump through to load a certificate:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/v7.06:/openssl.c#l261
through to the main load_certificate() function which ends at line
916. 

(You can ignore the entire contents of openssl-pkcs11.c for now.)

Even if you discount the TPM and PKCS#11 parts, it's bad enough for
just loading certificates from a file. We force the *application* to
inspect the file that the user asked it to use, and work out what kind
of file it is. And then even the handling of the *passphrase* is
different according to what kind of file it is — PKCS#12 functions need
the password handed in, while PEM functions are given a callback
function instead.

And don't even *talk* to me about the horridness with the TPM's UI
having no way to pass through any opaque data to the callback, and the
need for that 'static struct openconnect_info *ui_vpninfo' at line 276.
Actually, do talk to me about that. Let's fix it before 1.1?

We desperately need to provide applications with a function that
silently Does The Right Thing, when given a filename or a PKCS#11 URI
or whatever other string a user might put reasonably put into a config
file to specify a certificate/key.

> Shall we talk?

Absolutely :)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
> 
> sander> What I would like to see though is for such a PKCS#11 Engine
> sander> to be part of OpenSSL proper, so that our customers and
> sander> everyone else’s don’t have to go hunt hither and yon for bits
> sander> and bobs of software in order to make their hardware kit work
> sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
> sander> include in its distribution?
> 
> I'm not sure if this is a problem specifically for OpenSSL to solve,
> or if it is a packager problem. 

I touched on this in a message a few minutes ago, but I *definitely*
think it's the former.

If we integrate the support natively into OpenSSL, then PKCS#11 URIs
(see RFC7512) can be first-class citizens throughout the crypto and SSL
APIs. Any function which takes a filename for a cert or key should also
accept¹ a PKCS#11 URI.

Then we can also use PKCS#11 for the trust database, which allows us to
properly handle the trusted *purposes* in ways that a flat file
doesn't. And that flat file is now *exported* from the p11-kit-trust
token purely for the benefit of OpenSSL, which it would be nice to stop
doing.

I am happy to work on this.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


¹ Or "have a parallel function which takes"... but seriously, how often is
  a string which starts "pkcs11:" going to have been intended as a an
  actual *filename*? :)


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Ubsec and Chil engines

[David Woodhouse]

On Fri, 2016-02-19 at 15:53 +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-02-19 at 13:12 +, Matt Caswell wrote:
> 
> > As far as I know there are some customers using the Chil engine
> > > with
> > > RHEL (openssl-1.0.1). 
> > 
> > How do you feel about the engine being spun out into a separate
> > repo?
> > That of course assumes that a volunteer can be found to maintain it
> > (I
> > don't believe anyone on the dev team wishes to do so).
> > 
> > If no such volunteer can be found how big a deal is it to remove it
> > from
> > 1.1.0 without a replacement? Obviously it won't be taken out of
> > 1.0.1/1.0.2. Of course there's no reason, even if we take it out
> > now,
> > that if someone needs it badly enough in the future that they
> > couldn't forward port the 1.0.2 version to 1.1.0 and maintain it
> > themselves at that point.
> 
> It may even be better, instead of pushing for different engines for
> different hardware, to make PKCS#11 the only API used to talk to
> hardware. There is a quite functional (and active as project) pkcs11
> engine for openssl [0].

Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
to die, and be replaced by native code in openssl/crypto/pkcs11/

That way we can integrate it *properly*, with various SSL certificate
handling functions just naturally taking PKCS#11 URIs alongside
filenames.

Integrating libp11 itself would require relicensing it, which might be
non-trivial but perhaps still achievable. Or maybe we should
reimplement it, basing the new version around p11-kit.

It would be an *optional* thing, of course. Windows builds might
default to no-pkcs11. But p11-kit ought to exist fairly much everywhere
*else*.

Apart from UEFI :)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

[David Woodhouse]

On Wed, 2016-02-17 at 17:43 +, Salz, Rich wrote:
> > It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
> > to work "out of the box".
> 
> That will be great.
>  
> > I would like to see what we can do in the way of automated testing,
> > though. It should be possible to at least have Travis-CI make
> > libcrypto.so for the Linux target, with the 'no-everything' options
> > that UEFI uses. It's a blunt instrument, but would have caught quite a
> > few of the things I've just fixed, I think.
> 
> I think UEFI is important and would be willing to add a build to our travis.  
> Make a PR :)

I think the simplest build test looks something like this:

./Configure linux-x86_64 no-asm no-async no-bf no-camellia no-capieng \
  no-cast no-cms no-ct no-deprecated no-dgram no-dsa \
  no-dynamic-engine no-ec no-engine no-err no-filenames no-hw \
  no-idea no-locking no-mdc2 no-posix-io no-rc2 no-rfc3779 no-ripemd \
  no-scrypt no-sct no-seed no-sock no-srp no-ssl no-stdio no-threads \
  no-ts no-ui no-whirlpool shared     &&      make build_libcrypto

I'll try to work out how to put that into travis.

Once the fixes for RT4309 and RT4715 are merged, I'll also look at
testing actual EDK2 builds with the nightly snapshots.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

[David Woodhouse]

On Tue, 2016-02-09 at 02:57 +, Long, Qin wrote:
>  these two weeks.>
> 
> David, I agree it's really horrid to include those _lcl.h to meet
> EDK2 API requirement.  I am thinking it's better to re-design some
> APIs to align the new opaque structure style. E.g. replacing the
> HmacSha1GetContextSize() with HmacSha1ContextNew()... It should be
> feasible. 

That sounds ideal; thanks.

In the meantime, I've sorted out everything we need on the OpenSSL
side. A bunch has been merged today (thanks, Rich and Matt), and we are
now down to the following four RT tickets and associated pull requests:

 RT4175: Fix regression using PKCS7_verify() with Authenticode
 https://github.com/openssl/openssl/pull/694
(https://github.com/openssl/openssl/pull/695 for 1.0.2)

 RT4309: Define PRIu64 for UEFI build
 https://github.com/openssl/openssl/pull/696
 
 RT4310: Fix breakage of various no-xxx configuration options in HEAD 
 https://github.com/openssl/openssl/pull/697

 RT3628: Allow filenames to be eliminated from compiled library
 https://github.com/openssl/openssl/pull/698

It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
to work "out of the box".

I would like to see what we can do in the way of automated testing,
though. It should be possible to at least have Travis-CI make
libcrypto.so for the Linux target, with the 'no-everything' options
that UEFI uses. It's a blunt instrument, but would have caught quite a
few of the things I've just fixed, I think.

> In addition, I would like to retire the IntrinsicLib in CryptoPkg.
> This library is designed to satisfy the link requirement when
> integrating openssl in EDKII environment. Some code segments in
> OpenSSL will produce the intrinsic functions. E.g.  in the function
> load_iv() in Pem_lib.c: 
> for (i = 0; i < num; i++)
> to[i] = 0;
> I think it's better to update this to the direct memset(). What's
> your opinion?

I am not keen. 

If you don't want the compiler to 'spot' that certain patterns in C
code can be replaced with intrinsic functions, then ask it nicely not
to do that. Do *not* just attempt to tweak the code so that today's
compiler doesn't happen to spot anything it can replace, in the
*current* phase of the moon. That way lies madness.

Isn't this what -ffreestanding (or is it -fno-builtins) is for?

How does this work elsewhere in the EDK2 code base? Surely you can't play 
whack-a-mole with *every* piece of code  that the compiler might decide to swap 
for an intrinsic memset/memcpy/etc., including all structure assignments?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4318] [PATCH] Fix OSSL_SSIZE_MAX for UEFI build

[David Woodhouse via RT]

Commit e634b448c ("Defines OSSL_SSIZE_MAX") introduced a definition of
OSSL_SSIZE_MAX which broke the UEFI build. Fix that by making UEFI take
the same definition as Ultrix (ssize_t == int).
---
 include/openssl/e_os2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index 1a1fe3e..8cf6c84 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -269,7 +269,7 @@ extern "C" {
 #  endif
 # endif
 
-# if defined(__ultrix) && !defined(ssize_t)
+# if (defined(__ultrix) || defined(OPENSSL_SYS_UEFI)) && !defined(ssize_t)
 #  define ossl_ssize_t int
 #  define OSSL_SSIZE_MAX INT_MAX
 # endif
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4318
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4315] [PATCH] Fix UEFI build in crypto/init.c

[David Woodhouse via RT]

We don't have atexit() in the EDK2 environment. Firmware never exits.
---
 crypto/init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/init.c b/crypto/init.c
index 25e3dc7..c7eff8b 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -270,7 +270,9 @@ static void ossl_init_base(void)
 fprintf(stderr, "OPENSSL_INIT: ossl_init_base: Setting up stop 
handlers\n");
 #endif
 ossl_init_setup_thread_stop();
+#ifndef OPENSSL_SYS_UEFI
 atexit(OPENSSL_cleanup);
+#endif
 OPENSSL_cpuid_setup();
 base_inited = 1;
 }
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4315
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4313] [PATCH] Fix build for !IMPLEMENTED code path in CRYPTO_secure_free()

[David Woodhouse via RT]

Commit 05c7b1631 ("Implement the use of heap manipulator implementions")
added 'file' and 'line' arguments to CRYPTO_free() and friends, but neglected
to fix up the !IMPLEMENTED case within CRYPTO_secure_free(). Add the missing
arguments there too.
---
 crypto/mem_sec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/mem_sec.c b/crypto/mem_sec.c
index be3bb9a..fdda487 100644
--- a/crypto/mem_sec.c
+++ b/crypto/mem_sec.c
@@ -138,7 +138,7 @@ void CRYPTO_secure_free(void *ptr, const char *file, int 
line)
 sh_free(ptr);
 UNLOCK();
 #else
-CRYPTO_free(ptr);
+CRYPTO_free(ptr, file, line);
 #endif /* IMPLEMENTED */
 }
 
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4313
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev