[Asterisk-code-review] STIR/SHAKEN: Fix certificate type and storage. (asterisk[16])

[Benjamin Keith Ford]

Benjamin Keith Ford has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15822 )

Change subject: STIR/SHAKEN: Fix certificate type and storage.
......................................................................


Patch Set 3:

(3 comments)

https://gerrit.asterisk.org/c/asterisk/+/15822/3/configs/samples/stir_shaken.conf.sample 
File configs/samples/stir_shaken.conf.sample:

https://gerrit.asterisk.org/c/asterisk/+/15822/3/configs/samples/stir_shaken.conf.sample@25 
PS3, Line 25: ; A certificate store is used to examine, and load all certificates found in a
            : ; given directory. When using this type the public key URL is generated based
            : ; upon the filename, and variable substitution.
> > This functionality isn't yet implemented (we've got an issue for it), but these will be for our ow […]
Not the ones we've retrieved. Those are downloaded and saved in a static location, there is no user control over that.


https://gerrit.asterisk.org/c/asterisk/+/15822/3/configs/samples/stir_shaken.conf.sample@51 
PS3, Line 51: ; URL to the public certificate. Must be of type X509. This will be put in the identity header
            : ; when signing.
            : ;public_key_url=http://mycompany.com/alice.pem
> > This is different from path. […]
Ah, yeah. I can make a note of that.
As for store, they are exactly the same except that all the certificates in a store will be located in the same place - variable substitution will be used when reading them in to replace ${CERTIFICATE} with the filename of anything it finds in the directory (including for public_key_url). It's just a way to bulk load certificates if you have several and don't want to configure them individually.


https://gerrit.asterisk.org/c/asterisk/+/15822/3/res/res_stir_shaken.c 
File res/res_stir_shaken.c:

https://gerrit.asterisk.org/c/asterisk/+/15822/3/res/res_stir_shaken.c@618 
PS3, Line 618: 	if (public_key_is_expired(public_key_url)) {
> > Yeah, Richard is right here. There's a chance that it could be expired on the server itself. […]
There's an issue to look into all of this when updating the expiration code. Adding it to this review would make it too big I think, and it would make more sense in an upcoming review just to separate out some of the concerns. Might need to add additional functions that do the individual checks.



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/15822
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: Ia00b20835f5f976e3603797f2f2fb19672d8114d
Gerrit-Change-Number: 15822
Gerrit-PatchSet: 3
Gerrit-Owner: Benjamin Keith Ford <bford at digium.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Joshua Colp <jcolp at sangoma.com>
Gerrit-CC: Richard Mudgett <rmudgett at digium.com>
Gerrit-Comment-Date: Mon, 03 May 2021 14:13:35 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: George Joseph <gjoseph at digium.com>
Comment-In-Reply-To: Benjamin Keith Ford <bford at digium.com>
Comment-In-Reply-To: Richard Mudgett <rmudgett at digium.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20210503/9837bf84/attachment.html>