Re: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal review process

[Shane Lontis]

Vote [+1]
I view this as a bug fix.

From: openssl-project  on behalf of Nicola 
Tuveri 
Sent: Wednesday, November 16, 2022 1:00 AM
To: OpenSSL Project 
Subject: [External] : OTC Vote: Accept PR #19681 in 3.1 subject to normal 
review process

Topic: Accept PR #19681 in 3.1 subject to normal review process
Comment: Fundamentally OTC must decide if in the 3.1 release we should
 honor OSSL_PKEY_PARAM_EC_POINT_CONVERSION_FORMAT as set (and
 default to UNCOMPRESSED) in our provider implementations, and
 apply corresponding changes for handling legacy keys.
Proposed by: Nicola Tuveri
Issue link: 
https://urldefense.com/v3/__https://github.com/openssl/technical-policies/issues/59__;!!ACWV5N9M2RV99hQ!OqxV4GXROeksWaZKdnkB2ZxFaBT1TMeCLMYCMBN_CfR0LiFEzx5F_7W1GJsGD8ObcYVsuXTdGuyPaZKP$
Public: yes
Opened: 2022-11-15
Closed: -MM-DD
Accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: W)

  Dmitry [  ]
  Matt   [  ]
  Pauli  [  ]
  Tim[  ]
  Hugo   [  ]
  Richard[  ]
  Shane  [  ]
  Tomas  [  ]
  Kurt   [  ]
  Matthias   [  ]
  Nicola [+1]

Re: [External] : OTC VOTE: Accept Policy change process proposal

[Shane Lontis]

+1


From: openssl-project  on behalf of Tomas 
Mraz 
Sent: Monday, November 1, 2021 8:23 PM
To: openssl-project@openssl.org 
Subject: [External] : OTC VOTE: Accept Policy change process proposal

topic: Accept openssl/technical-policies PR#1 - the policy change
process proposal as of commit 3bccdf6. This will become an official OTC
policy.

comment: This will implement the formal policy change process so we can
introduce and amend further policies as set by OTC via a public
process.

Proposed by Tomáš Mráz
Public: yes
opened: 2021-11-01
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

   Dmitry [  ]
   Matt   [  ]
   Pauli  [  ]
   Tim[  ]
   Richard[  ]
   Shane  [  ]
   Tomas  [+1]
   Kurt   [  ]
   Matthias   [  ]
   Nicola [  ]

Re: [External] : Agenda for the next OTC meeting

[Shane Lontis]

I would like to also discuss code coverage, and in particular adding tests for 
any new code that is added.

From: openssl-project  on behalf of Matt 
Caswell 
Sent: Tuesday, October 12, 2021 10:23 PM
To: openssl-project@openssl.org 
Subject: [External] : Agenda for the next OTC meeting

My proposed agenda for the next OTC meeting (2021-10-19):

1) Nominate a minute taker and confirm agenda
2) Review policy process strawman
3) PR #16725
4) Agree agenda for next meeting
5) AOB


Matt

Re: [External] : OTC VOTE: Accept PR 16128

[Shane Lontis]

+1


From: openssl-project  on behalf of Matt 
Caswell 
Sent: Thursday, July 22, 2021 10:51 PM
To: openssl-project@openssl.org 
Subject: [External] : OTC VOTE: Accept PR 16128

topic: Accept PR 16128 in 3.0 subject to our normal review process
Proposed by Matt Caswell
Public: yes
opened: 2021-07-22
closed: 2021-mm-dd
accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)

   Matt   [+1]
   Pauli  [  ]
   Tim[  ]
   Richard[  ]
   Shane  [  ]
   Tomas  [  ]
   Kurt   [  ]
   Matthias   [  ]
   Nicola [  ]

Re: [External] : OTC VOTE: Reject PR#14759

[SHANE LONTIS]

+1

Shane


> On 20 Apr 2021, at 8:23 pm, Nicola Tuveri  wrote:
> 
> Following up on 
> https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html 
> 
>  we had a discussion on this during last week OTC meeting, and opened a vote 
> limited exclusively to the matter of rejecting PR#14759.
> 
> We lost the record of the votes collected during the call, so opening it 
> officially today with a clean slate.
> 
> 
> 
> topic: Reject PR#14759
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2021-04-20
> closed: 2021-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>   Matt   [  ]
>   Mark   [  ]
>   Pauli  [  ]
>   Viktor [  ]
>   Tim[  ]
>   Richard[  ]
>   Shane  [  ]
>   Tomas  [  ]
>   Kurt   [  ]
>   Matthias   [  ]
>   Nicola [+1]
> 
> 

Re: [External] : Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[SHANE LONTIS]

Nicola we already have a interface that sets blinding to on or off..


> On 9 Apr 2021, at 9:48 am, Nicola Tuveri  wrote:
> 
> Thanks for the feedback Tim! 
> I see your points and I value the discussion. 
> 
> Reading your message I realized that probably I got carried away in some of 
> the details in the lengthy email, and lost focus on part of the message I 
> wanted to convey.
> 
> Setting aside the matter of secure by default designs, 
> I don't oppose having a property system to let users select whatever 
> implementation from a menu of available implementations.
> But when these are boolean properties as proposed in the PR, they should be 
> objective properties with a universally clear definition that is immutable 
> over time and clear cut between yes/no. 
> 
> This is not the case for blinding=yes because it is not a boolean property. 
> In most cases a blinding implementation does "some" blinding at some level, 
> but does not blind every single computation. 
> Moreover the "amount" of blinding that qualifies an implementation as 
> performing the minimum required blinding changes over time, over threat 
> models, different standardizing bodies/different subjective considerations: 
> it's not an objective property of an algorithm implementation.
> blinding=no has better semantics because you could define it as "this 
> implementation intentionally avoids any kind of blinding", and that would be 
> an objective, universal, and immutable definition.
> Same applies for consttime=yes vs consttime=no.
> Then I went on blabbing about the downsides of the =no variants of this, 
> because they are cases that don't admit a well defined =yes counterpart. I 
> included that to justify why I don't believe that flipping the flag logic 
> here would be enough to make the PR acceptable (IMO). 
> 
> I would not oppose this PR if it was defining a property string to mark 
> another objective quality of the implementation: e.g. 
> supports_cofactor_ecdh=yes vs =no, or compressed_format=yes, batching=yes, 
> multiprime=yes, padding=this_or_that_padding_standard as I don't argue about 
> having the provider=whatever that qualifies the origin of an implementation, 
> or labvalidated=cert_program_xyz, ISOx_score=3.14 and similar things.
> Those properties have clear definitions and could be perfectly useful for 
> apps and end-users to choose among a rich menu of alternatives. No objection 
> there.
> 
> You make another point with which I tend to disagree strongly: some 
> actionable information must be better than no information at all. 
> 
> I agree with it when it is stated like that, but I believe that is not the 
> case if the "some information" has a high risk of being actually 
> "disinformation". 
> In such cases the extra information can actually do more harm than good, e.g. 
> false sense of security, misled choices, risks of ossification, technical 
> debt, maintenance burden, etc.
> 
> What leads me to qualify blinding=yes as a property string with high risks of 
> quickly degrading into disinformation? The fact that it has ill-defined 
> semantics as I verbosely tried to argument.
> 
> The bits about the scope of well-definedness (apologies I fail to phrase this 
> in a better way) are both to support the above argument and to start a 
> discussion on how to establish criteria that would allow coordination among 
> the project and our community (incouding different provider authors and the 
> end-users) so that there is process to create well-defined shared property 
> strings for those qualities that cannot be reduced to definitions given by 
> some existing standardization body.
> In such a propquery program, I am of the opinion that "applies 
> countermeasures to prevent some side-channel attacks" should be deemed 
> unacceptable because of the reasons stated above, and rejected. 
> 
> 
> 
> Thanks again for you feedback, I hope this time I did a better job of 
> separating the concerns I have about the semantics of the proposed property 
> string and on the need to establish some guidance to have some degree of 
> coherence in the definition of property strings.
> I see it already as a problem that in this and the previous email a lot of my 
> arguments had to be prefixed with "in my opinion" because we lack a framework 
> to guide our own choices.
> 
> 
> Nicola
> 
> 
> P.S. aside from the main topic, I understand provider authors are free to 
> define and use properties as they see fit, and we are not limiting that 
> freedom in my proposal. But we need a framework to guide our decisions in 
> soundly designing and defining our own properties, and also a system to allow 
> coordinated properties when desirable (which is relevant here because 
> blinding=yes is an attempt at establishing a shared property definition for 
> end-users and 3rd party providers, given that its only purpose is to let 
> end-users decide among some of our implementations or some yet to come 3rd 
> party 

Re: [External] : OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely

[SHANE LONTIS]

0



> On 23 Feb 2021, at 8:21 pm, Tomas Mraz  wrote:
> 
> topic: The RSA_SSLV23_PADDING and related functions should be
> completely removed from OpenSSL 3.0 code.
> 
> comment: The padding mode and the related functions (which are already
> deprecated in the current master branch) is useless outside of SSLv2
> support. We do not support SSLv2 and we do not expect anybody using
> OpenSSL 3.0 to try to support SSLv2 by calling those functions.
> 
> Proposed by Tomas Mraz.
> 
> public: yes
> opened: 2021-02-23
> 
> 
> 

Re: OTC VOTE: Keeping API compatibility with missing public key

[SHANE LONTIS]

+1


> On 4 Dec 2020, at 10:45 pm, Tomas Mraz  wrote:
> 
> Vote background
> ---
> 
> The vote on relaxing the conceptual model in regards to required public
> component for EVP_PKEY has passed with the following text:
> 
> For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without
> public components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not contain public keys and
> * our decoders unconditionally generate the public key (where
> possible).
> 
> However since then the issue 13506 [1] was reported.
> 
> During OTC meeting we concluded that we might need to relax also other
> public key algorithm implementations to allow private keys without
> public component.
> 
> Vote
> 
> 
> topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable
>   with 1.1.1 EVP_PKEY API or low level APIs without public component must
>   stay usable.
> 
>   This overrules the
> * all implementations apart from EC require the public component to 
> be present;
>   part of the vote closed on 2020-11-17.
> 
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-12-04
> 
> Tomas Mraz
> 
> 

Re: OTC VOTE: Fixing missing failure exit status is a bug fix

[SHANE LONTIS]

+1


> On 30 Nov 2020, at 10:03 pm, Nicola Tuveri  wrote:
> 
> Vote background
> ---
> 
> This follows up on a [previous proposal] that was abandoned in favor of
> an OMC vote on the behavior change introduced in [PR#13359].
> Within today's OTC meeting this was further discussed with the attending
> members that also sit in the OMC.
> 
> The suggestion was to improve the separation of the OTC and OMC domains
> here, by having a more generic OTC vote to qualify as bug fixes the
> changes to let any OpenSSL app return an (early) failure exit status
> when a called function fails.
> 
> The idea is that, if we agree on this technical definition, then no OMC
> vote to allow a behavior change in the apps would be required in
> general, unless, on a case-by-case basis, the "OMC hold" process is
> invoked for whatever reason on the specific bug fix, triggering the
> usual OMC decision process.
> 
> [previous proposal]:
>   >
> [PR#13359]: 
>   >
> 
> 
> 
> Vote text
> -
> 
> topic: In the context of the OpenSSL apps, the OTC qualifies as bug
>   fixes the changes to return a failure exit status when a called
>   function fails with an unhandled return value.
>   Even when these bug fixes change the apps behavior triggering
>   early exits (compared to previous versions of the apps), as bug
>   fixes, they do not qualify as behavior changes that require an
>   explicit OMC approval.
> Proposed by Nicola Tuveri
> Public: yes
> opened: 2020-11-30

Re: OTC VOTE: EVP_PKEY private/public key components

[SHANE LONTIS]

Key assurance  really depends on what you are doing, so I don't think this is 
quite true.
For example if you generate a key using a valid algorithm (that is validated by 
a lab), then there is already an assurance that the key is valid without 
needing to run EVP_PKEY_check().

There are many operations that don't need EVP_PKEY_check, but they may need a 
sub check such as
EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or 
EVP_PKEY_pairwise_check (or some combination of those).
Keys (and certs) that are received from another entity should be validated 
unless there is some other mechanism for establishing that the key is trusted.


> On 12 Nov 2020, at 12:14 am, Nicola Tuveri  wrote:
> 
> In light of recently working more closely to `EVP_PKEY_check()` I
> would add to the discussion on this vote that it is not entirely true
> that we were not enforcing the keypair assumption and that the current
> strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t.
> some uses that work in 1.1.1.
> 
> In particular in 1.1.1, the key created as depicted in #12612 that
> triggered this discussion (Matt posted a useful reproducer among the
> first comments), is indeed capable of signing in the used pattern, but
> the pattern is conveniently omitting the validation pass that should
> be required in any serious use of the API.
> 
> `EVP_PKEY_check()`
> (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$
>  ) is
> one of the many places in 1.1.1 where both the documentation and the
> behavior assume that an `EVP_PKEY` object is a keypair.
> Even in the version used by the user that posted the issue, running
> `EVP_PKEY_check()` on the created key would have revealed that the
> user was abusing the API.
> 
> The "lack of enforcement" argument, that was partially at the base of
> formulating the vote text as it is, and conditioned our votes, seems
> to me an intentional design choice, as part of preferring the usage
> pattern "validate once, and reuse many times": for performance reasons
> we are not running `EVP_PKEY_check()` on every single key loaded from
> a PEM file or created by the user, but there is an assumption that the
> user did validate at least once the key material using
> `EVP_PKEY_check()` or `openssl pkey -check`.
> So enforcement was never lacking, but it was relegated together with
> more expensive checks, into functions that the user should execute at
> least once, possibly according to well documented security policies
> concerning the management of key material in transit and at rest.
> 
> Omitting the `EVP_PKEY_check()` in the reproducer and the user
> application, would for example allow me to write a DoS attack: the
> secret scalar could easily be hand-picked to trigger an endless loop
> in the sign operation.
> 
> 
> --
> 
> Nicola
> 
> 
> 
> On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell  wrote:
>> 
>> Background to the vote:
>> 
>> The OTC meeting today discussed the problems raised by issue #12612. In
>> summary the problem is that there has been a long standing, widespread
>> and documented assumption that an EVP_PKEY with a private key will
>> always also have the public key component.
>> 
>> In spite of this it turns out that in the EC implementation in 1.1.1 it
>> was perfectly possible to create an EVP_PKEY with only a private key and
>> no public key - and it was also possible to use such an EVP_PKEY in a
>> signing operation.
>> 
>> The current 3.0 code in master introduced an explicit check (in line
>> with the long held assumption) that the public key was present and
>> rejected keys where this was not the case. This caused a backwards
>> compatibility break for some users (as discussed at length in #12612).
>> 
>> The OTC discussed a proposal that we should relax our conceptual model
>> in this regards and conceptually allow EVP_PKEYs to exist that only have
>> the private component without the public component - although individual
>> algorithm implementations may still require both.
>> 
>> It is possible to automatically generate the public component from the
>> private for many algorithms, although this may come at a performance and
>> (potentially) a security cost.
>> 
>> The proposal discussed was that while relaxing the conceptual model,
>> most of the existing implementations would still require both. The EC
>> implementation would be relaxed however. This essentially gives largely
>> compatible behaviour between 1.1.1 and 3.0.
>> 
>> The vote text is as follows:
>> 
>> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
>> * relax the conceptual model to allow private keys to exist without public
>>  components;
>> * all implementations apart from EC require the public component to be
>> present;
>> * relax implementation for EC key management to allow private keys that
>> do not
>>  contain public keys 

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

[SHANE LONTIS]

-1


> On 9 Oct 2020, at 7:40 am, Dr Paul Dale  wrote:
> 
> +1
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 9 Oct 2020, at 12:27 am, Matt Caswell > > wrote:
>> 
>> topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as
>> shown in PR #13018 into the 3.0 release
>> Proposed by Matt Caswell
>> Public: yes
>> opened: 2020-10-08
>> closed: 2020-mm-dd
>> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
>> 
>>  Matt   [+1]
>>  Mark   [  ]
>>  Pauli  [  ]
>>  Viktor [  ]
>>  Tim[  ]
>>  Richard[  ]
>>  Shane  [  ]
>>  Tomas  [  ]
>>  Kurt   [  ]
>>  Matthias   [  ]
>>  Nicola [  ]
> 

Re: Vote proposal: Private keys can exist independently of public keys

[SHANE LONTIS]

I assume you are just talking about the ec key?

If the public key is not present then that could be seen as an error for 
operations that require the public key. 

Shane

> On 7 Oct 2020, at 9:54 pm, Dr Paul Dale  wrote:
> 
> Would it be feasible to change code that does ->pub_key to call a function 
> that null checks the field and generates the public key if it is absent?
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 7 Oct 2020, at 9:29 pm, Matt Caswell > > wrote:
>> 
>> Issue #12612 exposes a problem with how we handle keys that contain
>> private components but not public components.
>> 
>> There is a widespread assumption in the code that keys with private
>> components must have public components. There is text in our public
>> documentation that states this (and that text dates back to 2006).
>> 
>> OTOH, the code has not always enforced this. Issue #12612 describes a
>> scenario where this has not historically been enforced, and it now is in
>> the current 3.0 code causing a regression.
>> 
>> There are differences of opinion on how this should be handled. Some
>> have the opinion that we should change the model so that we explicitly
>> allow private keys to exists without the public components. Others feel
>> that we should continue with the old model.
>> 
>> It seems we need a vote to decide this. Here is my proposed vote text:
>> 
>> We should change the 3.0 code to explicitly allow private components to
>> exist in keys without the public components also being present.
>> 
>> Feedback please on the proposed vote text.
>> 
>> Matt
> 

Re: Freeze?

[SHANE LONTIS]

I think this best describes the issue:
https://www.youtube.com/watch?v=zsKOYQ7z9CE 



> On 26 Sep 2020, at 9:17 am, Benjamin Kaduk  wrote:
> 
> On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote:
>> I’m seeing quite a bit of activity going on which isn’t related to the 
>> 3.0beta1 milestone.
>> We’re well past the cutoff date announced for new features in the code.
>> 
>> Should we be limiting the “new” stuff going in?
>> 
>> I’m fine with bug fixes, they make sense.  I’m fine with the list of beta1 
>> pull requests continuing.
>> It’s the rest that is more concerning.
>> 
>> Does anyone else have a similar view?
> 
> I think we should probably avoid putting in large or potentially
> destabilizing changes, but don't see much reason to put a total freeze in
> place (even with your listed exceptions).
> 
> -Ben

Re: Reordering new API's that have a libctx, propq

[SHANE LONTIS]

The example given was EVP_PKEY_get_() and from the API name it is fairly clear 
what the first param should be EVP_PKEY *pkey (the API tells you this).

For the fetch case, I still think that the algorithm is the most important 
param.
Libctx, propq are optional parameters as far as I am concerned.

If it is decided that the libctx is more important then the API should really 
be something like this..
OSSL_LIBCTX_MD_fetch(), (and I dont know if that is a good idea.)..

In some places where libctx is used it is a second class parameter whose only 
job is to perform a sub task of fetching during a bigger operation (such as in 
a load),
And in these cases it should not be the first parameter..

Shane

> On 6 Sep 2020, at 4:02 pm, Richard Levitte  wrote:
> 
> There are many red herrings in here, and I would argue that trying to
> be too uniform in the way you think about all functions may be
> harmful, because not all functions are classified the same.
> 
> We cannot deny that many of our interfaces have an OOP flair.  We may
> be programming in C, but we very obviously have that kind of pattern,
> a "poor man's OOP" in C.  So speaking about our interfaces in OOP
> terms is not far fetched, as long as we keep in mind that we can only
> take the argument so far.
> 
> I would argue that EVP_XXX_get_whatever() / EVP_XXX_get_whatever() are
> classic accessors, and I assume that we have all been brought up with
> the description of "this" as the hidden first argument to any class
> method in C++, so it's not very far fetched to emulate that in C by
> making the instance you want details from or change details of as the
> (explicit) first argument.
> 
> I would further argue that EVP_XXX_fetch() is a constructor (of an
> instance of EVP_XXX), and that with the assumption that there is no
> "this" in a constructor, the discussion about the arguments and their
> order must be different.
> 
> What I hear, even though not in such terms, is an argument of the
> what the library context is and how that should affect the interface.
> In relation to EVP_XXX_fetch(), it seems to be more of a factory (or
> strictly speaking, the pool of resources, with hidden factory
> functions), and depending on the factory model you lean on, it might
> or might not be sensible to have it as first argument.  My you, I'm
> trying quite hard to see it from a fresh user experience (as far as I
> can imagine it...  after all, 20ish years with my fingers deep in
> OpenSSL entrails makes you not so fresh).
> 
> I think, BTW, that this really comes down to how we view the library
> context.  So far, I've seen all these interpretations (not all said
> explicitly, but clearly visible in code or how we argue about it):
> 
> - framework
> - scope (I'm unsure if that differs much from framework)
> - factory / factory pool
> - bag of resources
> 
> Personally, I have zero problems viewing it as all of these combined,
> but that requires us to be clear on how it's used in different places.
> 
> Cheers,
> Richard
> 
> On Sat, 05 Sep 2020 23:18:21 +0200,
> Tim Hudson wrote:
>> 
>> 
>> On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte  wrote:
>> 
>>I'd rank the algorithm name as the most important, it really can't do
>>anything of value without it.
>> 
>> It also cannot do anything without knowing which libctx to use. Look at the 
>> implementation.
>> Without the libctx there is no "from-where" to specify. 
>> 
>> This is again hitting the concept of where do things come from and what is a 
>> default.
>> Once "global" disappears as such, logically everything comes from a libctx.
>> 
>> Your argument is basically "what" is more important than "from" or "where".
>> And the specific context here is where you see "from" or "where" can be 
>> defaulted to a value so it
>> can be deduced so it isn't (as) important in the API.
>> 
>> That would basically indicate you would (applying the same pattern/rule in a 
>> different context)
>> change:
>> 
>> int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int *out);
>> 
>> To the following (putting what you want as the most important rather than 
>> from):
>> 
>> int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out);
>> 
>> Or pushing it right to the end after the output parameter:
>> 
>> int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey);
>> 
>> The context of where things come from is actually the most critical item in 
>> any of the APIs we
>> have.
>> Even though what you want to get from where you want to get it is in the 
>> point of the API call you
>> need to specify where from first as that context sets the frame of the call.
>> 
>> Think of it around this way - we could have an implementation where we 
>> remember the last key that
>> we have used and allow you to simply indicate you use the last key or if we 
>> didn't want the last
>> key used to be able to specify it via a non-NULL pointer. This isn't that 
>> unusual an API but not
>> something I'm 

Re: Reordering new API's that have a libctx, propq

[SHANE LONTIS]

Thanks for the writeup..

> My view is that the importance of arguments is what sets their order - and 
> that is why for the TYPE functions the TYPE pointer
> comes first. We could have just as easily specified it as last or some other 
> order, but we didn’t.

Isn’t that the order that the fetch is in if it changes to what it is in the 
PR? I would argue that the algorithm is the most important parameter in the 
fetch.

Deciding what argument is more ‘important’ is not always easy either.
If we are doing an operation such as a get or load and it needs a whole lot of 
input params in order to return something,
then aren’t they more important/ or just as important as the libctx,propq - 
(since the libctx,propq is just used normally to fetch something)?
This then means the libctx ends up last, or maybe in the middle again.

Also it is quite common for the new() methods (such as for X509) to need both 
the libctx and propq..
The X509 object gets passed to an d2i method that internally needs to do 
fetches (SHA1) and cache.

Shane

> On 5 Sep 2020, at 5:09 pm, Tim Hudson  wrote:
> 
> My view is that the importance of arguments is what sets their order - and 
> that is why for the TYPE functions the TYPE pointer
> comes first. We could have just as easily specified it as last or some other 
> order, but we didn't.

Reordering new API's that have a libctx, propq

[SHANE LONTIS]

PR #12778 reorders all the API’s of the form:

EVP_XX_fetch(libctx, algname, propq) 

So that the algorithm name appears first.. 

e.g: EVP_MD_fetch(digestname, libctx, propq);

This now logically reads as 'search for this algorithm using these parameters’.

The libctx, propq should always appear together as a pair of parameters.
There are only a few places where only the libctx is needed, which means that 
if there is no propq it is likely to cause a bug in a fetch at some point. 

This keeps the API’s more consistent with other existing XXX_with_libctx API’s 
that put the libctx, propq at the end of the parameter list..
The exception to this rule is that callback(s) and their arguments occur after 
the libctx, propq..

e.g:
typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
(const OSSL_STORE_LOADER *loader,
 const char *uri, OPENSSL_CTX *libctx, const char *propq,
 const UI_METHOD *ui_method, void *ui_data);

An otc_hold was put on this.. Do we need to have a formal vote?
This really needs to be sorted out soon so the API’s can be locked down for 
beta.


Also discussed in a weekly meeting and numerous PR discussions was the removal 
of the long winded API’s ending with ‘with_libctx’
e.g CMS_data_create_with_libctx
The proposed renaming for this was to continue with the _ex notation.. If there 
is an existing _ex name then it becomes _ex2, etc.
There will most likely be additional parameters in the future for some API’s, 
so this notation would be more consistent with current API’s.
Does this also need a vote?

Regards,
Shane

Re: RAND_DRBG

[SHANE LONTIS]

i.e.  Choose option (1)

> On 27 Jul 2020, at 11:14 am, SHANE LONTIS  wrote:
> 
> If this is not going to break 99% of users + it improves the interface + the 
> replacement to achieve the same is a few lines of code and is likely to occur 
> in one place in an app, then it seems reasonable to change it to me.
> 
> 
>> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > <mailto:paul.d...@oracle.com>> wrote:
>> 
>> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
>> with the move to provider based infrastructure.
>> They are definitely being deprecated in master but without more, the extra 
>> layer of indirection and additional complexity generating random numbers 
>> will remain.
>> 
>> The option I see are:
>> 
>> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking 
>> change.
>> 2. Bypass RAND_DRBG and live with a breaking change (refer: 
>> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 
>> <https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12509*pullrequestreview-455396828__;Iw!!GqivPVa7Brio!P_SYCN9POdf1ZT1I7v4h9G_oUTuels90DxKk1JmFkD7HcXsTPr9n0s3FX3XZZo_c2Q$>)
>> 3. Leave things as they currently are in master.
>> 
>> The first two are breaking changes and will require an OMC vote.
>> 
>> 
>> Some pertinent points:
>> 
>> 1. RAND_bytes will continue to work as is — this API is perfect for almost 
>> everyone.
>> 2. The RAND_METHOD functionality remains — this allows wholesale replacement 
>> of OpenSSL’s RNGs if desired.
>> 3. The name EVP_RAND is the working name and might change — this is not 
>> relevant to this discussion.
>> 4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced 
>> in 1.1.1.  The two users I know of (Akamai and NCP) are both fine with them 
>> being removed.
>> 
>> 
>> Thoughts anyone?
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
> 

Re: RAND_DRBG

[SHANE LONTIS]

If this is not going to break 99% of users + it improves the interface + the 
replacement to achieve the same is a few lines of code and is likely to occur 
in one place in an app, then it seems reasonable to change it to me.


> On 27 Jul 2020, at 11:08 am, Dr Paul Dale  wrote:
> 
> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
> with the move to provider based infrastructure.
> They are definitely being deprecated in master but without more, the extra 
> layer of indirection and additional complexity generating random numbers will 
> remain.
> 
> The option I see are:
> 
> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking 
> change.
> 2. Bypass RAND_DRBG and live with a breaking change (refer: 
> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828 
> )
> 3. Leave things as they currently are in master.
> 
> The first two are breaking changes and will require an OMC vote.
> 
> 
> Some pertinent points:
> 
> 1. RAND_bytes will continue to work as is — this API is perfect for almost 
> everyone.
> 2. The RAND_METHOD functionality remains — this allows wholesale replacement 
> of OpenSSL’s RNGs if desired.
> 3. The name EVP_RAND is the working name and might change — this is not 
> relevant to this discussion.
> 4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced 
> in 1.1.1.  The two users I know of (Akamai and NCP) are both fine with them 
> being removed.
> 
> 
> Thoughts anyone?
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 

Re: API renaming

[SHANE LONTIS]

As @levitte pointed out - it was not back ported (not sure why I thought it 
was) 

> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre 
>  wrote:
> 
> > I think the KDF and MAC got back ported also...
>  
> In this case it would be no question that we should keep the names EVP_KDF 
> and EVP_MAC.
>  
>  
>Dr. Matthias 
> St. Pierre 
> 
> Senior Software Engineer 
> matthias.st.pie...@ncp-e.com  
> Phone: +49 911 9968-0
> www.ncp-e.com 
> 
> 
> Follow us on: Facebook 
> 
>  | Twitter 
> 
>  | Xing 
> 
>  | YouTube 
> 
>  | LinkedIn 
> 
> 
> Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
> Nuremberg 
> North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
> Clearwater, FL 33755 
> 
> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich 
> Registry Court: Lower District Court of Nuremberg 
> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
> 133557619
> 
> This e-mail message including any attachments is for the sole use of the 
> intended recipient(s) and may contain privileged or confidential information. 
> Any unauthorized review, use, disclosure or distribution is prohibited. If 
> you are not the intended recipient, please immediately contact the sender by 
> reply e-mail and delete the original message and destroy all copies thereof.
> 
> 

Re: API renaming

[SHANE LONTIS]

I was thinking OSSL_LIBCTX?

> On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre 
>  wrote:
> 
> I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with 
> Shane
> that we should go for a single prefix and not have two alternatives. Existing 
> prefixes
> for things like feature macros should remain as they are, but if the OSSL_ 
> prefix is
> our choice for the future, we should start using it consistently for _all_ 
> new APIs in 3.0.
> And not make it a random choice (pun intended) depending on whether the API 
> went
> into master early or late. So my favorite choice is a consistent renaming, 
> i.e.
> 
>   OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ...
> 
> OTOH, it would be ok for me if we would make an exception for EVP_MAC and 
> EVP_KDF,
> because they have a long EVP history, as Matt pointed out. But using the EVP_ 
> prefix
> for the new RAND interface never made sense to me.
> 
> What bothers me about OPENSSL_CTX in particular is the fact that it is a 
> mixture of
> a non-abbreviated and an abbreviated word. IMHO it should be either OSSL_CTX 
> or
> OPENSSL_CONTEXT, and the former is obviously preferrable for its length.
> 
> Matthias
> 
> 
>> -Original Message-
>> From: openssl-project  On Behalf Of 
>> Richard Levitte
>> Sent: Friday, July 24, 2020 8:34 AM
>> To: openssl-project@openssl.org
>> Subject: Re: API renaming
>> 
>> I'm fine with that, really.
>> 
>> I have a preference for OSSL_, but if we look through the source,
>> there's reason for either.  So far, we've majorly used OPENSSL_ for
>> things like feature macros (disabling macros, really), environment
>> variables, that sort of thing, while OSSL_ has become the primary
>> choice for new APIs ("less klunky", I think the judgement was in that
>> past discussion I keep referring to).
>> 
>> And yeah, I hear you from all the way around the planet, there are
>> some recent name choice that were made that give pause and are
>> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
>> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
>> I have no problem recognising that.  But, they are there, even though
>> only in master (*).  This is question of what we do going forward (a
>> yet unmerged PR with a new API is as good a target as any).
>> 
>> Cheers,
>> Richard
>> 
>> (*) I'm not sure I see master as something untouchable in this regard,
>> as the development is still not frozen (alpha), so I for one could
>> easily see a rename fest happening, should we decide for it.  That
>> must happen before we enter the beta phase, though...
>> 

Re: API renaming

[SHANE LONTIS]

I think the KDF and MAC got back ported also...

> On 24 Jul 2020, at 4:33 pm, Richard Levitte  wrote:
> 
> I'm fine with that, really.
> 
> I have a preference for OSSL_, but if we look through the source,
> there's reason for either.  So far, we've majorly used OPENSSL_ for
> things like feature macros (disabling macros, really), environment
> variables, that sort of thing, while OSSL_ has become the primary
> choice for new APIs ("less klunky", I think the judgement was in that
> past discussion I keep referring to).
> 
> And yeah, I hear you from all the way around the planet, there are
> some recent name choice that were made that give pause and are
> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
> I have no problem recognising that.  But, they are there, even though
> only in master (*).  This is question of what we do going forward (a
> yet unmerged PR with a new API is as good a target as any).
> 
> Cheers,
> Richard
> 
> (*) I'm not sure I see master as something untouchable in this regard,
> as the development is still not frozen (alpha), so I for one could
> easily see a rename fest happening, should we decide for it.  That
> must happen before we enter the beta phase, though...
> 
> On Fri, 24 Jul 2020 07:55:10 +0200,
> SHANE LONTIS wrote:
>> 
>> For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’  is not a particularly great 
>> rule either.
>> We should decide which one to use and stick to it.
>> 
>>> On 24 Jul 2020, at 3:20 pm, Richard Levitte  wrote:
>>> 
>>> A couple of points:
>>> 
>>> 1.  Quite a while ago, we (the team at the time) made a decision to
>>>   have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'.  It seems
>>>   that we never voted on it, though, but still.
>>> 
>>> 2.  The new RAND API hasn't been merged yet, so it's not like we're
>>>   renaming something that already exists.
>>> 
>>> So in terms of "it's just a prefix", OSSL_ would be just as suitable.
>>> It's a bit more blatantly "OpenSSL", though.
>>> 
>>> Cheers,
>>> Richard
>>> 
>>> On Thu, 23 Jul 2020 23:30:25 +0200,
>>> Tim Hudson wrote:
>>>> Placing everything under EVP is reasonable in my view. It is just a prefix 
>>>> and it really has no
>>>> meaning these days as it became nothing more than a common prefix to use.
>>>> 
>>>> I don't see any significant benefit in renaming at this point - even for 
>>>> RAND.
>>>> 
>>>> Tim.
>>>> 
>>>> On Fri, 24 Jul 2020, 1:56 am Matt Caswell,  wrote:
>>>> 
>>>>   On 23/07/2020 16:52, Richard Levitte wrote:
>>>>> On Thu, 23 Jul 2020 12:18:10 +0200,
>>>>> Dr Paul Dale wrote:
>>>>>> There has been a suggestion to rename EVP_RAND to OSSL_RAND.  This seems 
>>>>>> reasonable.  Would
>>>>   it
>>>>>> also make sense to rename the other new APIs similarly.
>>>>>> More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF 
>>>>>> respectively?
>>>>> 
>>>>> This is a good question...
>>>>> 
>>>>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
>>>>> APIs, they have a previous history of EVP APIs, through EVP_PKEY.  The
>>>>> impact of relocating them outside of the EVP "family" may be small,
>>>>> but still, history gives me pause.
>>>>> 
>>>>> RAND doesn't carry the same sort of history, which makes it much
>>>>> easier for me to think "just do it and get it over with"...
>>>> 
>>>>   I have the same pause - so  I'm thinking just RAND for now.
>>>> 
>>>>   Matt
>>>> 
>>>> 
>>> -- 
>>> Richard Levitte levi...@openssl.org
>>> OpenSSL Project 
>>> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
>>>  
>> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project 
> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!LSCv_eY9cQfTVYkr1BXae4hxPy7nvs5sQQo1POAOF9yQFVSUvHdlaFUwYGSPI67pMw$
>  

Re: API renaming

[SHANE LONTIS]

For (1) the use of either ‘OPENSSL_' OR ‘OSSL_’  is not a particularly great 
rule either.
We should decide which one to use and stick to it.

> On 24 Jul 2020, at 3:20 pm, Richard Levitte  wrote:
> 
> A couple of points:
> 
> 1.  Quite a while ago, we (the team at the time) made a decision to
>have all new APIs prefixed with 'OPENSSL_' or 'OSSL_'.  It seems
>that we never voted on it, though, but still.
> 
> 2.  The new RAND API hasn't been merged yet, so it's not like we're
>renaming something that already exists.
> 
> So in terms of "it's just a prefix", OSSL_ would be just as suitable.
> It's a bit more blatantly "OpenSSL", though.
> 
> Cheers,
> Richard
> 
> On Thu, 23 Jul 2020 23:30:25 +0200,
> Tim Hudson wrote:
>> Placing everything under EVP is reasonable in my view. It is just a prefix 
>> and it really has no
>> meaning these days as it became nothing more than a common prefix to use.
>> 
>> I don't see any significant benefit in renaming at this point - even for 
>> RAND.
>> 
>> Tim.
>> 
>> On Fri, 24 Jul 2020, 1:56 am Matt Caswell,  wrote:
>> 
>>On 23/07/2020 16:52, Richard Levitte wrote:
>>> On Thu, 23 Jul 2020 12:18:10 +0200,
>>> Dr Paul Dale wrote:
 There has been a suggestion to rename EVP_RAND to OSSL_RAND.  This seems 
 reasonable.  Would
>>it
 also make sense to rename the other new APIs similarly.
 More specifically, EVP_MAC and EVP_KDF to OSSL_MAC and OSSL_KDF 
 respectively?
>>> 
>>> This is a good question...
>>> 
>>> Historically speaking, even though EVP_MAC and EVP_KDF are indeed new
>>> APIs, they have a previous history of EVP APIs, through EVP_PKEY.  The
>>> impact of relocating them outside of the EVP "family" may be small,
>>> but still, history gives me pause.
>>> 
>>> RAND doesn't carry the same sort of history, which makes it much
>>> easier for me to think "just do it and get it over with"...
>> 
>>I have the same pause - so  I'm thinking just RAND for now.
>> 
>>Matt
>> 
>> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project 
> https://urldefense.com/v3/__http://www.openssl.org/*levitte/__;fg!!GqivPVa7Brio!KL97HvjYmS7a3QKC8tJzRlM2dM4t9WLQOYHSX50pDVuxB5XrRy5zA3onhN1dMVGCCw$
>  

Re: OpenSSL version 3.0.0-alpha1 published

[SHANE LONTIS]

Thanks..

I will take a look.

Shane


> On 2 May 2020, at 2:20 am, Guido Vranken  wrote:
> 
> Reminder that in git master and 3.0.0, CAST5 gives the wrong output: 
> https://github.com/openssl/openssl/issues/11459 
> 
>  (this proof of concept was made before you moved CAST5 to liblegacy, so just 
> put OSSL_PROVIDER_load(nullptr, "legacy"); in there to make it work)
> 
> On Thu, Apr 23, 2020 at 4:30 PM OpenSSL  > wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
>OpenSSL version 3.0 alpha 1 released
>
> 
>OpenSSL - The Open Source toolkit for SSL/TLS
>https://www.openssl.org/ 
> 
> 
>OpenSSL 3.0 is currently in alpha.
> 
>OpenSSL 3.0 alpha 1 has now been made available.
> 
>Note: This OpenSSL pre-release has been provided for testing ONLY.
>It should NOT be used for security critical purposes.
> 
>Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
>as known issues are available on the OpenSSL Wiki, here:
> 
> https://wiki.openssl.org/index.php/OpenSSL_3.0 
> 
> 
>The alpha release is available for download via HTTPS and FTP from the
>following master locations (you can find the various FTP mirrors under
>https://www.openssl.org/source/mirror.html 
> ):
> 
>  * https://www.openssl.org/source/ 
> 
>  * ftp://ftp.openssl.org/source/ 
> 
> 
>The distribution file name is:
> 
> o openssl-3.0.0-alpha1.tar.gz
>   Size: 9530120
>   SHA1 checksum:  4db145d3d9c9d7bfaa7b2a1fe1670f7a3781bb06
>   SHA256 checksum:  
> 9d5be9122194ad1d649254de5e72afd329252f134791389d0cef627b18ed9a57
> 
>The checksums were calculated using the following commands:
> 
> openssl sha1 openssl-3.0.0-alpha1.tar.gz
> openssl sha256 openssl-3.0.0-alpha1.tar.gz
> 
>Please download and check this $LABEL release as soon as possible.
>To report a bug, open an issue on GitHub:
> 
> https://github.com/openssl/openssl/issues 
> 
> 
>Please check the release notes and mailing lists to avoid duplicate
>reports of known issues. (Of course, the source is also available
>on GitHub.)
> 
>Yours,
> 
>The OpenSSL Project Team.
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6hpQcACgkQ2cTSbQ5g
> RJHvtggAp7XIxm/00amD4TijQhJqMmGsj0RXqwAeSd0gWDQCf78GX4zMIW/tTgvk
> I3Mb67DsOR5gdPZN5TigyqRaXSIAzfb8ZT4Gs9lo/j8RUi5AmzT2RYexbRv6bF6E
> cQ0OabM3rk4qi4njTi/YD9YihO6/pv7tWZkkfPsN547bfm7p7fwCrEHw02En5IW8
> hyFhkpKfA3c8MEa96yLwjhkYRTAzUmxus/mNID+Ja3/VTCmHjd1c57SHFPq9noll
> Wqzhs3jEhluZKHpwmSSA0KQh1ph0kh6fnKLEn3Oge5dYV3P+JrFCRfDEMsI1Nb/F
> hIr11rxXNxtBRKUSlOUyJATZn0sV6g==
> =uRpM
> -END PGP SIGNATURE-

Re: CI build timeouts

[SHANE LONTIS]

Disabling memory leak checking doesn’t sound like a great idea..

> On 31 Mar 2020, at 1:09 am, Salz, Rich  wrote:
> 
> It’s time to disable that build, isn’t it?
> It’s timing out *AFTER AN HOUR*
>  
> From: Tomáš Mráz mailto:notificati...@github.com>>
> Reply-To: openssl/openssl 
>  >
> Date: Monday, March 30, 2020 at 9:51 AM
> To: openssl/openssl  >
> Cc: Subscribed  >
> Subject: Re: [openssl/openssl] [crypto/ec] blind coordinates in ec_wNAF_mul 
> for robustness (#11439)
>  
>> The CI failure doesn't really make sense to me.
> That's just an usual timeout unrelated to this PR.
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> ,
>  or unsubscribe 
> .

Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

[SHANE LONTIS]

FIPS_mode() and FIPS_mode_set() are functions that were used by the old FOM.

In OpenSSL_111 they were stripped down to do almost nothing
i.e:-

int FIPS_mode(void)  
{  
/* This version of the library does not support FIPS mode. */  
return 0;  
}

int FIPS_mode_set(int on)  
{
if (r == 0)  
return 1;

CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
return 0;  
}

The original plan for these API’s is listed in the design document for 3.0
i.e- the set would - set the global property and then do a fetch of a 
particular algorithm (this is problematic in itself since the algorithm may not 
exist for a 3rd party fips provider which could just implement a single 
algorithm).
And FIPS_mode() would just return true if the global property for fips was set.

This got some pushback and after discussion with a few other otc members - it 
was decided that the functions should be deprecated since it would be confusing 
to a user because there are multiple library contexts allowed each with their 
own fips property that can be changed at
any time.

This is done in https://github.com/openssl/openssl/pull/11075 
 and there is a related 
discussion in the comments.

This PR has also been rejected the deprecation and discusses
- FIPS_mode_set() function could be completely removed.
- FIPS_mode() - query using the default library context OR completely remove.

I have no issue with both functions being deleted as they no longer really mean 
the same thing as they did before.
Each library context has its own default properties - so querying FIPS_mode() 
could only return what the default library context’s fips properties are - it 
doesnt mean every library context is in fips mode, or even that the fips module 
is loaded. 
If the functions are removed then it may require a OMC vote since this could be 
viewed as a breaking change..

Does anyone have any thoughts on this?

Regards
Shane

Re: Deprecations

[SHANE LONTIS]

> On 22 Feb 2020, at 1:36 pm, Viktor Dukhovni  
> wrote:
> 
> But there's nothing like
> using a screwdriver to turn a screw, rather than banging it in with
> an all-purpose hammer!

If we are trying to tell users to not use the low level API’s, and then we go 
and use them everywhere in apps it is not really sending the correct message.
If we need to keep them - then they probably would need to be rewritten in 
terms of evp. (Or parse the parameters and pass them to another app call) :)). 
Either way its quite a bit of work.


> If you search internet, you will more than likely find the first
> ones. They are very easy. I have to look up at the manual page
> examples to know how to use genpkey.

Agreed. Being able to list all the pkey options from the app might be helpful 
here?

Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked?

[SHANE LONTIS]

With the new architecture changes there are quite a few new calls to

CRYPTO_UP_REF()
CRYPTO_DOWN_REF()

These methods return an int that is not being checked in lots of places.

This return value only seems to affect fallback code that calls 
CRYPTO_atomic_add (which can return 0 on lock or unlock failure)

SO the question is should we be checking this return value?


Note that not checking has resulted in a few assumptions in other code…
e.g the following function returns void.
 
/crypto/evp/keymgmt_lib.c: 165 in evp_keymgmt_util_cache_pkey()
159 }
160 
161 void evp_keymgmt_util_cache_pkey(EVP_PKEY *pk, size_t index,
162  EVP_KEYMGMT *keymgmt, void *keydata)
163 {
164 if (keydata != NULL) {
>>>CID 1458170:  Error handling issues  (CHECKED_RETURN)
>>>Calling "EVP_KEYMGMT_up_ref" without checking return value (as is done 
>>> elsewhere 4 out of 5 times).
165 EVP_KEYMGMT_up_ref(keymgmt);

NOTE: EVP_KEYMGMT_up_ref() just does an CRYPTO_UP_REF() call and always returns 
1.

Re: OSSL_PARAMs

[SHANE LONTIS]

I presume the reference approach was used to solve the issue of who actually 
owns/free's the data.
 

> On 5 Jun 2019, at 9:18 am, Dr Paul Dale  wrote:
> 
> Shane’s major complaints are about the indirection the OSSL_PARAM structure 
> forces — for integers and return lengths and the necessity of allocating 
> additional memory in parallel with the OSSL_PARAM.
> 
> The extra indirection was intended to support const arrays of OSSL_PARAM, 
> which turn out to be a rarity because they aren’t thread safe.  With most 
> OSSL_PARAM structure being dynamically created, the need for the indirection 
> seems redundant.  E.g. could the return length be moved into OSSL_PARAM?  I 
> think so.
> 
> Moving integral values into the structure is more difficult because BIGNUMs 
> will always need to be references.  Allocating additional memory will still 
> be required.  I’ve got three obvious solutions:
> 
> 1. include a void * in the OSSL_PARAM structure that needs to be freed when 
> the structure is destroyed or
> 2. have a block of data in the OSSL_PARAM structure that can be used for 
> native types (OSSL_UNION_ALIGN works perfectly for this) or
> 3. add a flag field to the OSSL_PARAM to indicate that the referenced value 
> needs to be freed.
> 
> The memory allocation comes to the for when reading e.g. a file and 
> extracting data — either the reader needs a lot of local variables to hold 
> everything or it has to allocated for each.  The file’s data is transient in 
> memory.
> 
> 
> For the most part, the receiver side APIs seem reasonable.  It is the owning 
> side that has the complications.
> 
> I think I might be able come up with some owner side routines that assist 
> here but allowing changes to the params structure would be far easier.
> 
> 
> I kind of like using the OSSL_PARAM arrays as a replacement for string ctrl 
> functions if not ctrl as well (subject to backward compatibility concerns).
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
>> On 4 Jun 2019, at 11:26 pm, Richard Levitte > > wrote:
>> 
>> On Tue, 04 Jun 2019 14:57:00 +0200,
>> Salz, Rich wrote:
>>> 
>>> 
   Part of the idea was that this would be a means of communication
>>>between application and provider, just like controls are with
>>>libcrypto sub-systems.
>>> 
>>> 
>>> I can probably find the email thread (or maybe it was a GitHub
>>> comment on my proposal for params), where you said, quite
>>> definitively, that this was *not* a general-purpose mechanism but
>>> rather a way to expose the necessary internals for opaque objects
>>> like RSA keys.
>> 
>> Either I misunderstood what you said at the time, or you misunderstood
>> what I said...  there's definitely a disconnect here somewhere.
>> 
>> What I wonder is why it should be exclusively only one of those
>> options?
>> 
>> Either way, the OSSL_PARAM is defined publically and openly (i.e.
>> non-opaque), and we currently have the following functions in the
>> public API:
>> 
>>EVP_MD_CTX_set_params
>>EVP_MD_CTX_get_params
>>OSSL_PROVIDER_get_params
>> 
>> I fully expect that more will come.  I have a branch where I've
>> EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if
>> EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before
>> long (I'm actually rather surprised they haven't already), and I'm
>> absolutely sure we will see similar functions for asymmetric
>> algorithms.
>> 
>>> What changed your mind?
>>> 
>>> Perhaps not surprisingly, I agree with Shane's assessment and am
>>> strongly opposed to the project foisting this on everyone at this
>>> time.  @DavidBen, your thoughts?
>> 
>> Maybe we're reading differently, I didn't see Shane being opposed to
>> parameter passing in this way per se, just the exact form of the
>> OSSL_PARAM structure, which is different.
>> 
>> Cheers,
>> Richard
>> 
>> -- 
>> Richard Levitte levi...@openssl.org 
>> OpenSSL Project http://www.openssl.org/~levitte/ 
>> 

Re: OSSL_PARAMs

[SHANE LONTIS]

The controls are easier to understand and use currently.
The advantage of params is that you can batch them, so that the order no longer 
matters during setup (e.g- I need to set EVP_MD first).

The params are not being used in anger yet.
My main problem with the params is that no data is set into them - only 
pointers to the data blob.
I find this to be a confusing interface which hurts my (tiny) brain (especially 
with types like strings)
I would prefer base types (like int to just be embedded in the set data - even 
if that meant allocs are needed).
My concern is that is the end user is supposed to use what we have currently, 
there are going to be many issues.

Shane

> On 4 Jun 2019, at 4:12 pm, Dr Paul Dale  wrote:
> 
> A question for the committers and beyond.
> 
> Should the OSSL_PARAM concept be used for more than just the libcrypto ⇿ 
> provider interface?
> 
> The one that springs to mind is a more general form of the various ctrl 
> calls, there are some string ctrl calls that attempt to do the same thing in 
> a less structured manner.
> 
> 
> Thoughts?
> 
> Pauli
> -- 
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 

Re: proposed change to committers policy

[SHANE LONTIS]

It doesn’t stop us both reviewing a PR. That doesn’t mean we both need to 
approve.


> On 24 May 2019, at 7:21 pm, Matthias St. Pierre 
>  wrote:
> 
> 
> 
> >   In considering approvals, the combined approvals must come
> >   from individuals who work for separate organisations.
> >   This condition does not apply where the organisation is the
> >   OSF or OSS.
> 
> 
> IMHO an important clarification needs to be made: The rule should not be about
> _prohibiting_ double approvals. It should only be about _counting_ them.
> I would not deprive people of the right to state their opinions.
> 
> Also, if Shane has already approved, then Pauli should still have the right
> to approve, since his approval counts as OMC approval and Shane's not.
> 
> How about using a formulation like the following?
> 
> In considering approvals, approvals from individuals being
> employed by the same third party company or organization should
> be counted as a single approval. If one of the individuals is
> an OMC member, the combined approval counts as an OMC approval.
> This condition does not apply where the organisation is the
> OSF or OSS.
> 
> 
> An editorial comment: I think that the amendmend should be made inside the
> unordered list, not following it.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_web_blob_master_policies_committers.html-23L72-2DL78=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=b1aL1L-m41VGkedIk-9Q7taAEKIshTBwq95Iah07uCk=DYHGYucybgbeMHQn9pS8SBhh_dvJkYrDgKu9gU2l9H4=jT3VTidhpkkMAwUuiu_JgqW9mBpD4PP-3Qc8D3KZDdU=
> 
> Apart from that: Tim, could you (or someone else of the OMC) please raise a PR
> for your proposal? That would make it easier to discuss the details.
> 
> Matthias
> 
>